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

Chapter 5: Creating and Altering Tables
There is a Windows API call to generate a GUID in normal programming, but, in addition to the ROWGUIDCOL
option on a column, SQL has a special function to return a GUID — it is called the NEWID() function,
and can be called at any time.
COLLATE
This works pretty much just as it did for the CREATE DATABASE command, with the primary difference
being in terms of scope (here, we define at the column level rather than the database level).
NULL/NOT NULL
This one is pretty simple — it states whether the column in question accepts NULL values or not. The
default, when you first install SQL Server, is to set a column to NOT NULL if you don’t specify nullability.
There are, however, a very large number of different settings that can affect this default, and change its
behavior. For example, setting a value by using the sp_dbcmptlevel stored procedure or setting ANSIcompliance
options can change this value.
Column Constraints
We have a whole chapter coming up on constraints, so we won’t spend that much time on it here. Still, it
seems like a good time to review the question of what column constraints are — in short, they are restrictions
and rules that you place on individual columns about the data that can be inserted into that column.
For example, if you have a column that’s supposed to store the month of the year, you might define that
column as being of type tinyint — but that wouldn’t prevent someone from inserting the number 54 in
that column. Since 54 would give us bad data (it doesn’t refer to a month), we might provide a constraint
that says that data in that column must be between 1 and 12. We’ll see how to do this in our next chapter.
Computed Columns
128
I highly recommend explicitly stating the NULL option for every column in every
table you ever build. Why? As I mentioned before, there are a large number of different
settings that can affect what the system uses for a default for the nullability of
a column. If you rely on these defaults, then you may find later that your scripts
don’t seem to work right (because you or someone else has changed a relevant setting
without realizing its full effect).
You can also have a column that doesn’t have any data of its own, but whose value is derived on the fly
from other columns in the table. If you think about it, this may seem odd since you could just figure it
out at query time, but really, this is something of a boon for many applications.
For example, let’s say that we’re working on an invoicing system. We want to store information on the
quantity of an item we have sold, and at what price. It used to be fairly commonplace to go ahead and
add columns to store this information, along with another column that stored the extended value (price
times quantity). However, that leads to unnecessary wasting of disk space and maintenance hassles
associated with when the totals and the base values get out of synch with each other. With a computed
column, we can get around that by defining the value of our computed column to be whatever multiplying
price by quantity creates.