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

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
As I stated early in this chapter, normalization is one of those things that database designers sometimes
wear like a cross. It’s somehow turned into a religion for them, and they begin normalizing data for the
sake of normalization rather than for good things it does to their database. Here are a couple of things to
think about in this regard:
❑ If declaring a computed column or storing some derived data is going to allow you to run a report
more effectively, then by all means put it in. Just remember to take into account the benefit vs.
the risk. (For example, what if your “summary” data gets out of synch with the data it can be
derived from? How will you determine that it happened, and how will you fix it if it does happen?)
❑ Sometimes, by including just one (or more) de-normalized column in a table, you can eliminate
or significantly cut down the number of joins necessary to retrieve information. Watch for these
scenarios — they actually come up reasonably frequently. I’ve dealt with situations where
adding one column to one commonly used base table cut a nine-table join down to just three,
and cut the query time by about 90 percent in the process.
❑ If you are keeping historical data — data that will largely go unchanged and is just used for
reporting — then the integrity issue becomes a much smaller consideration. Once the data is
written to a read-only area and verified, you can be reasonably certain that you won’t have “out
of sync” problems, which are one of the major problems that data normalization addresses. At
that point, it may be much nicer (and faster) to just “flatten” (de-normalize) the data out into a
few tables, and speed things up.
❑ The fewer tables that have to be joined, the happier your users who do their own reports are
going to be. The user base out there continues to get more and more savvy with the tools they
are using. Increasingly, users are coming to their DBA and asking for direct access to the database
to be able to do their own custom reporting. For these users, a highly normalized database can
look like a maze and become virtually useless. De-normalizing your data can make life much
easier for these users.
All that said, if in doubt, normalize things. There is a reason why that is the way relational systems are
typically designed. When you err on the side of normalizing, you are erring on the side of better data
integrity, and on the side of better performance in a transactional environment.
Beyond Normalization
In this section, we’re going to look into a basic set of “beyond normalization” rules of the road in design.
Very few of these are hard and fast kind of rules — they are just things to think about. The most important
thing to understand here is that, while normalization is a big thing in database design, it is not the
only thing.
Keep It Simple
248
I run into people on a regular basis who have some really slick ways to do things differently than it’s
ever been done before. Some of the time, I wind up seeing some ideas that are incredibly cool and incredibly
useful. Other times I see ideas that are incredibly cool, but not very useful. As often as not though, I see
ideas that are neither — they may be new, but that doesn’t make them good.