Datasheet

Chapter 1: Being Objective: Re-Examining Objects in SQL Server
NULL Data
What if you have a row that doesn’t have any data for a particular column — that is, what if you simply
don’t know the value? For example, let’s say that we have a record that is trying to store the company
performance information for a given year. Now, imagine that one of the fields is a percentage growth over
the prior year, but you don’t have records for the year before the first record in your database. You might
be tempted to just enter a zero in the
PercentGrowth column. Would that provide the right information
though? People who didn’t know better might think that meant you had zero percent growth, when the
fact is that you simply don’t know the value for that year.
Values that are indeterminate are said to be
NULL .ItseemsthateverytimeIteachaclassinprogramming,
at least one student asks me to define the value of
NULL . Well, that’s a tough one, because, by definition,
a
NULL value means that you don’t know what the value is. It could be 1; it could be 347; it could be –294
forallweknow.Inshort,itmeansundefined or perhaps not applicable.
SQL Server Identifiers for Objects
Now you’ve heard all sorts of things about objects in SQL Server. But let’s take a closer look at naming
objects in SQL Server.
What Gets Named?
Basically, everything has a name in SQL Server. Here’s a partial list:
Stored procedures Tables Columns
Views Rules Constraints
Defaults Indexes Filegroups
Triggers Databases Servers
User-defined functions Logins Roles
Full-text catalogs Files User-defined types
Schemas
And the list goes on. Most things I can think of except rows (which aren’t really objects) have a name.
The trick is to make every name both useful and practical.
Rules for Naming
The rules for naming in SQL Server are fairly relaxed, allowing things like embedded spaces and even
keywords in names. Like most freedoms, however, it’s easy to make some bad choices and get yourself
into trouble.
17