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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
Before I step too hard on your creative juices here, let me clarify what I’m trying to get across — don’t
accept the “because we’ve always done it that way” approach to things, but also recognize that the tried
and true probably continues to be tried for a reason — it usually works.
SQL Server 2008 continues to bring all new ways to overdo it in terms of making things too complex.
Complex data rules and even complex data types are available through powerful and flexible new additions
to the product (code driven functions and data types). Try to avoid instilling more complexity in
your database than you really need to. A minimalist approach usually (but not always) yields something
that is not only easier to edit, but also runs a lot faster.
Choosing Data Types
In keeping with the minimalist idea, choose what you need, but only what you need.
For example, if you’re trying to store months (as the number, 1-12) — those can be done in a single byte
by using a tinyint. Why then, do I regularly come across databases where a field that’s only going to
store a month is declared as an int (which is 4 bytes)? Don’t use an nchar or nvarchar if you’re never
going to do anything that requires Unicode — these data types take up two bytes for every one as compared
to their non-Unicode cousins.
There is a tendency to think about this as being a space issue. When I bring this up
in person, I sometimes hear the argument, “Ah, disk space is cheap these days!”
Well, beyond the notion that a name-brand SCSI hard drive still costs more than I
care to throw away on laziness, there’s also a network bandwidth issue. If you’re
passing an extra 100 bytes down the wire for every row, and you pass a 100 record
result, then that’s about 10K worth of extra data you just clogged your network with.
Still not convinced? Now, say that you have just 100 users performing 50 transactions
per hour — that’s over 50MB of wasted network bandwidth per hour.
The bottom line is, most things that happen with your database will happen repetitively
— that means that small mistakes snowball and can become rather large.
Err on the Side of Storing Things
There was an old movie called The Man Who Knew Too Much — Hitchcock I believe — that man wasn’t
keeping data.
Every time that you’re building a database, you’re going to come across the question of, “Are we going
to need that information later?” Here’s my two-bit advice on that — if in doubt, keep it. You see, most of
the time you can’t get back the data that has already come and gone.
I guarantee that at least once (and probably many, many more times than that), a customer (remember,
customers are basically anyone who needs something from you — there is such a thing as an internal customer,
not just the ones in Accounts Receivable) will come to you and say something like, “Can you
give me a report on how much we paid each non-incorporated company last year?”
249