SQL dot notation

Question

Can someone please explain to me how SQL Server uses dot notation to identify
the location of a table? I always thought that the location is Database.dbo.Table
But I see code that has something else in place of dbo, something like:
DBName.something.Table Can someone please explain this?

Answer 1

This is a database schema. Full three-part name of a table is:

databasename.schemaname.tablename

For a default schema of the user, you can also omit the schema name:

databasename..tablename

You can also specify a linked server name:

servername.databasename.schemaname.tablename

You can read more about using identifiers as table names on MSDN:

The server, database, and owner names are known as the qualifiers of the object name. When you refer to an object, you do not have to specify the server, database, and owner. The qualifiers can be omitted by marking their positions with a period. The valid forms of object names include the following:

server_name.database_name.schema_name.object_name

server_name.database_name..object_name

server_name..schema_name.object_name

server_name...object_name

database_name.schema_name.object_name

database_name..object_name

schema_name.object_name

object_name

An object name that specifies all four parts is known as a fully qualified name. Each object that is created in Microsoft SQL Server must have a unique, fully qualified name. For example, there can be two tables named xyz in the same database if they have different owners.

Most object references use three-part names. The default server_name is the local server. The default database_name is the current database of the connection. The default schema_name is the default schema of the user submitting the statement. Unless otherwise configured, the default schema of new users is the dbo schema.

Answer 2

When SQL sees the syntax it will first look at the current users schema to see if the table exists, and will use that one if it does. If it doesn't then it looks at the dbo schema and uses the table from there

Answer 3

What @Szymon said. You should also make a point of always schema-qualifying object references (whether table, view, stored procedure, etc.) Unqualified object references are resolved in the following manner:

• Probe the namespace of the current database for an object of the specified name belonging to the default schema of the credentials under which the current connection is running.

• If not found, probe the namespace of the current database for an object of the specified name belonging to the dbo schema.

And if the object reference is to a stored procedure whose name begins with sp_, it's worse, as two more steps are added to the resolution process (unless the references is database-qualified): the above two steps are repeated, but this time, looking in the database master instead of the current database.

So a query like

select *
from foo

requires two probes of the namespace to resolve foo (assuming that the table/view is actually dbo.foo): first under your default schema (john_doe.foo) and then, not being found, under dbo (dbo.foo'), whereas

select *
from dbo.foo

is immediately resolved with a single probe of the namespace.

This has 3 implications:

1. The redundant lookups are expensive.

2. It inhibits query plan caching, as every execution has to be re-evaluated, meaning the query has to be recompiled for every execution (and that takes out compile-time locks).

3. You will, at one point or another, shoot yourself in the foot, and inadvertently create something under your default schema that is supposed to exist (and perhaps already does) under the dbo schema. Now you've got two versions floating around.

   At some point, you, or someone else (usually it happens in production) will run a query or execute a stored procedure and get...unexpected results. It will take you quite some time to figure out that there are two [differing] versions of the same object, and which one gets executed depends on their user credentials and whether or not the reference was schema-qualified.

Always schema-qualify unless you have a real reason not to.

That being said, it can sometimes be useful, for development purposes to be able to maintain the "new" version of something under your personal schema and the "current" version under the 'dbo' schema. It makes it easy to do side-by-side testing. However, it's not without risk (which see above).