Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 5: Creating and Altering Tables
Now, let’s say that there is also a user with a login name of Fred. Fred is the database owner (as opposed
to just any member of db_owner). If Fred creates a table called MyTable using an identical CREATE
statement to that used by MySchema, the two-part table name will be dbo.MyTable. In addition, as dbo
also happens to be the default owner, any user could just refer to the table as MyTable.
It’s worth pointing out that members of the sysadmin role (including the sa login) always alias to the dbo.
That is, no matter who actually owns the database, a member of sysadmin will always have full access
as if it were the dbo, and any objects created by a member of sysadmin will, unless explicitly defined
otherwise, show ownership belonging to the dbo. In contrast, objects created by members of the db_owner
database role do not default to dbo as the default schema — they will be assigned to whatever that particular
user has set as the default schema (it could be anything). Weird but true!
In chats I had with a few old friends at Microsoft, they seemed to be somewhat on the schema bandwagon
and happy for the changes. I too am happy for the changes, but mostly because they make the use of
schemas easier, not because schemas are a feature that I think everyone should rush to use.
The addition of schemas adds complexity to your database no matter what you do. While they can address
organizational problems in your design, those problems can usually be dealt with in other ways that
produce a much more user-friendly database. In addition, schemas, while an ANSI/ISO-compliant notion,
are not supported in the same way across every major RDBMS product. This means using schemas is
going to have an impact on you if you’re trying to write code that can support multiple platforms.
The Database Name
The next item in the fully qualified naming convention is the database name. Sometimes you want to
retrieve data from a database other than the default, or current, database. Indeed, you may actually want
to JOIN data from across databases. A database-qualified name gives you that ability. For example, if you
were logged in with AdventureWorks2008 as your current database, and you wanted to refer to the Orders
table in the Accounting database we’ll be building later in the chapter, then you could refer to it by
Accounting.dbo.Orders. Since dbo is the default schema, you could also use Accounting..Orders.
If a schema named MySchema owns a table named MyTable in MyDatabase, then you could refer to that
table as MyDatabase.MySchema.MyTable. Remember that the current database (as determined by the
USE command or in the drop-down box if you’re using the SQL Server Management Studio) is always
the default, so, if you want data from only the current database, then you do not need to include the
database name in your fully qualified name.
Naming by Server
116
In addition to naming other databases on the server you’re connected to, you can also “link” to another
server. Linked servers give you the capability to perform a JOIN across multiple servers — even different
types of servers (SQL Server, Oracle, DB2, Access — just about anything with an OLE DB provider).
We’ll see a bit more about linked servers later in the book, but for now, just realize that there is one more
level in our naming hierarchy, that it lets you access different servers, and that it works pretty much like
the database and ownership levels work.
Now, let’s just add to our previous example. If we want to retrieve information from a server we have
created a link with called MyServer, a database called MyDatabase, and a table called MyTable owned
by MySchema, then the fully qualified name would be MyServer.MyDatabase.MySchema.MyTable.