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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
I’ve touched on this before, but you just about have to drag me kicking and screaming in order to get me
to allow nulls in my databases. There are situations where you just can’t avoid it — “undefined” values
are legitimate. I’ll still often fill text fields with actual text saying “Value Unknown” or something like
that.
The reason I do this is because nullable fields promote errors in much the same way that undeclared
variables do. Whenever you run across null values in the table you wind up asking yourself, “Gee, did I
mean for that to be there, or did I forget to write a value into the table for that row?” — that is, do I
have a bug in my program?
The next issue we faced was default values. We couldn’t have a default for OrderID because we’re making
it an identity column (the two are mutually exclusive). For OrderDate, however, a default made some
level of sense. If an OrderDate isn’t provided, then we’re going to assume that the order date is today.
Last, but not least, is the CustomerNo — which customer would we default to? Nope — can’t do that here.
Next up was the issue of an identity column. OrderID is an ideal candidate for an identity column —
the value has no meaning other than keeping the rows unique. Using a counter such as an identity field
gives us a nice, presentable, and orderly way to maintain that unique value. We don’t have any reason to
change the identity seed and increment, so we won’t. We’ll leave it starting at one and incrementing by one.
Now we’re ready to move on to our next table — the OrderDetails table as defined in Figure 8-25.
Figure 8-25
For this table, the OrderID column is going to have a foreign key to it, so our data type is decided for
us — it must be of the same type and size as the field it’s referencing, so it’s going to be an int.
The LineItem is going to start over again with each row, so we probably could have gotten as little as a
tinyint here. We’re going to go with an int on this one just for safety’s sake. (I’ve had people exceed
limits that have been set on this sort of thing before.)
PartNo is, for this table, actually going to be defined by the fact that it needs to match up with the PartNo
in the Products table. It’s going to be using a char(6) in that table (we’ll come to it shortly), so that’s
what we’ll make it here.
Qty is guesswork. The question is, what’s the largest order you can take as far as quantity for one lineitem
goes? Since we don’t know what we’re selling, we can’t really make a guess on a maximum quantity
(for example, if we were selling barrels of oil, it might be bought literally millions of barrels at a time).
We’re also using an int here, but we would have needed a data type that accepted decimals if we were
selling things like gallons of fuel or things by weight, so be sure to consider your needs carefully.
253