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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
252
Note that I’ve changed from the default view — which doesn’t have Default Value
and Identity as part of it — over to the “custom” view. I also had to choose to Modify
Custom and select the Default Value and Identity columns to be added to my custom
view.
Let’s stop long enough to look at a couple of the decisions that we made here. While we had addressed
the issue of normalization, we hadn’t addressed any of the other basics yet. First up of those was the
question of data types.
Because OrderID is the primary key for the table, we need to be sure that we allow enough room for our
values to be unique as we insert more and more data. If this was a table we weren’t going to be making
very many inserts into, we might choose a smaller data type, but since it is our Orders table (and we hope
to be entering lots of orders), we’ll push the size up a bit. In addition, numeric order numbers seem suitable
(make sure you ask your customers about issues like this) and facilitate the use of an automatic
numbering mechanism in the form of an identity column. If you need more than 2 billion or so order
numbers (in which case, I may want some stock in your company), you can take a look at the larger BigInt
data type. (Suffice to say that I’m certain you won’t have too many orders for that data type to hold —
just keep in mind the extra space used, although that’s often trivial in the larger schema of how much
space the database as a whole is using.)
With OrderDate, we’ve gone with the new Date data type. You may want to utilize one of the DateTime
data types instead if you want the time of day on your order in addition to just the date. Date is more
compact and meets the need for our simple invoicing database. Be careful in your DateTime data type
choices though; you’ll find that some of them work easier in some languages than others do. For example,
Visual Basic prior to .NET threw fits when you played around with smalldatetime fields, and could
even be temperamental with the then standard DateTime. You could get around the problems, but it
was a pain. Even with .NET, you’re generally going to want to use the newer DateTime2 data type
instead of DateTime, as it has a more direct crossover to the DateTime data type in .NET.
Our customer has told us (and we’ve seen in the earlier sample data), that CustomerNo is five digits, all
numeric. This is one of those areas where you start saying to your customer, “Are you sure you’re never
going to be using alpha characters in there?” Assuming the answer is yes, we can go with an integer
since it is:
❑ Faster on lookups.
❑ Smaller in size — 4 bytes will cover a 5-digit number easily, but it takes 5 bytes minimum (6 if
you’re using variable-length fields) to handle 5 characters.
Note that we’re kind of cheating on this one — realistically, the customer number for this table is really
being defined by the relationship we’re going to be building with the Customers table. Since that’s the
last table we’ll see in this example, we’re going ahead and filling in the blanks for this field now.
After data types, we also had to decide on the size of the column — this was a no-brainer for this particular
table since all the data types have fixed sizes.
Next on the hit list is whether the rows can be null or not. In this case, we’re sure that we want all this
information and that it should be available at the time we enter the order, so we won’t allow nulls.