db.name should be broken down into individual layers

[damiangarbacz]

What are you trying to achieve?
Semantic convention for db client calls (database.md) states that for db.name "the database name to be used is the more specific layer". This may cause problems because as a user I don't know beforehand what the tag actually describes. For one db engine the tag may describe the "schema name" and for another a "database name".

This approach also makes it difficult to distinguish e.g. between two schemas with the same schema name running under two different instances.

I believe that db.name should behave consistently regardless of the database engine used (always store "database name"). Moreover it might be helpful to add more tags to describe database-specific layers (like db.schema_name or something similar).

Additional context.
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/database.md

[carlosalberto]

We need experts here, as well as examples to document actual, specific cases (e.g. different databases). Please consider raising in the semantic convention group with @jsuereth (albeit this is a trace semantic convention).

[trask]

The reasoning behind db.name being the "more specific layer" is so that you can use it to contextualize db.sql.table in a backend UI. This is similar in spirit to #521 which is about shoe-horning different database-specific names into a single attribute which represents the same thing conceptually.

The alternative is to go with more db-specific attributes which use database-specific terminology, e.g. db.oracle.schema_name and db.oracle.instance_name. This can add more clarity for people already familiar with these databases, but it can add more complexity to backends trying to visualize the data across all databases.

[trask]

I believe we can close this after merging #911, as it clarifies the naming and purpose around this attribute (db.namespace instead of db.name).