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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
Let me reiterate the importance of being sure that your customers are really considering their future
needs. The PartNo column using a simple 6-character field is an example of where you might want to
be very suspicious. Part numbers are one of those things that people develop new philosophies on almost
as often as my teenage daughter develops new taste in clothes. Today’s inventory manager will swear
that’s all they ever intend to use and will be sincere in it, but tomorrow there’s a new inventory manager
or perhaps your organization merges with another organization that uses a 10-digit numeric part number.
Expanding the field isn’t that bad of a conversion, but any kind of conversion carries risks, so you want
to get it right the first time.
Description is one of those guessing games. Sometimes a field like this is going to be driven by your
user interface requirements (don’t make it wider than can be displayed on the screen), other times you’re
just going to be truly guessing at what is “enough” space. Here you use a variable-length char over a
regular char for two reasons:
❑ To save a little space
❑ So we don’t have to deal with trailing spaces (look at the char vs. varchar data types back in
Chapter 1 if you have questions on this)
We haven’t used an nchar or nvarchar because this is a simple invoicing system for a U.S. business,
and we’re not concerned about localization issues. If you’re dealing with a multilingual scenario, you’ll
want to pay much more attention to the Unicode data types. You’ll also want to consider them if you’re
storing inherently international information such as URLs, which can easily have kanji and similar characters
in them.
Weight is similar to Description in that it is going to be somewhat of a guess. We’ve chosen a tinyint
here because our products will not be over 255 pounds. Note that we are also preventing ourselves from
keeping decimal places in our weight (integers only). As we discussed back under PartNo, make sure
you consider your needs carefully — conservative can be great, but being over-conservative can cause a
great deal of work later.
We described the CustomerNo field back when we were doing the Orders table.
CustomerName and CustomerAddress are pretty much the same situation as Description — the question
is, how much is enough? But we need to be sure that we don’t give too much.
As before, all fields are required (there will be no nulls in either table) and no defaults are called for.
Identity columns also do not seem to fit the bill here as both the customer number and part number have
special formats that do not lend themselves to the automatic numbering system that an identity provides.
Adding the Relationships
OK, to make the diagram less complicated, I’ve gone through all four of my tables and changed the view
on them down to just Column Names. You can do this, too, by simply right-clicking on the table and
selecting the Column Names menu choice.
You should get a diagram that looks similar to Figure 8-28.
255