Datasheet

Chapter 1: Being Objective: Re-Examining Objects in SQL Server
Here are the main rules:
❑ The name of your object must start with any letter as defined by the specification for Unicode 3.2.
This includes the letters most westerners are used to — A–Z and a–z. Whether ‘‘A’’ is different
from ‘‘a’’ depends on the way your server is configured, but either makes for a valid beginning
to an object name. After that first letter, you’re pretty much free to run wild; almost any character
will do.
❑ The name can be up to 128 characters for normal objects and 116 for temporary objects.
❑ Any names that are the same as SQL Server keywords or contain embedded spaces must be
enclosed in double quotes (
"" )orsquarebrackets( [] ). Which words are considered keywords
varies, depending on the compatibility level to which you have set your database.
Note that double quotes are acceptable as a delimiter for column names only if you have set
QUOTED_IDENTIFIER on. Using square brackets ( [ and ] ) eliminates the chance that your users
will have the wrong setting but is not as platform independent as double quotes are. I do, however,
recommend against having
QUOTED IDENTIFIER on due to issues it can create with indexed views.
These rules are generally referred to as the rules for identifiers and are in force for any objects you name
in SQL Server. Additional rules may exist for specific object types.
I can’t stress enough the importance of avoiding the use of SQL Server keywords or
embedded spaces in names. Although both are technically legal a s long as you
qualify them, naming things this way will cause you no end of grief.
Summary
Database data has type,justasmostotherprogrammingenvironments do. Most things that you do in
SQL Server are going to have at least some consideration of type. While very little has changed in terms
of basic objects available in SQL Server 2008, several new data types have been added. Be sure and review
these new types (in the date and time arena as well as hierarchical data support). Review the types that
are available, and think about how these types map to the data types in any programming environment
with which you are familiar.
Consider the many objects available to you in SQL Server 2008. While you should be pretty familiar
with tables and the basics of views and scripting prior to using this book (if not, you may want to take
a look at Beginning SQL Server 2008 Programming), my hope is that you also realize that tossing together
a few tables and a stored procedure or two seldom makes a real database. The things that make today’s
RDBMSs great are the extra things — the objects that enable you to place functionality and business rules
that are associated with the data right into the database with the data.
18