Can You Be Less Specific?

SQL Server MVP Deep Dives 2, Chapter 6

Generalization: the key to a well-designed schema – by Paul Nielson (B|T)

Chapter six is the shortest chapter in the book so far, but Mr. Nielson uses that space very well to put forth the idea of generalization within a database design. Generalization isn’t the opposite of normalization, but it can help a database that seems to be over-normalized. He argues that “over-normalized” is the wrong term and you can keep normalization while reducing complexity in design by generalizing.

Continue reading


Louis’s Law

SQL Server MVP Deep Dives 2, Chapter 4

Characteristics of a Great Relational Database – by Louis Davidson (B|T)

I believe chapter four of Deep Dives 2 should be required reading for all non-database developers. It is not only a great overview of what makes up a good database design, but speaks to why it is best to design things in a relational way. Data architects don’t sit around plotting how to make life difficult for developers (that is just a side benefit), but they design a SQL Server database to make the best use of the relational database engine. Davidson lists out seven criteria for good database design with the added requirement that “it works.” “It works” is sort of the bare minimum for a database and it needs to be kept in mind or all of the effort of designing the database is meaningless. When I read chapter four I was reminded of the Boy Scout Law listing the characteristics scouts strive for. I took Davidson’s criteria and wrote it out as Louis’s Law.

A Relational Database is Coherent, Normal, Fundamentally Sound, Documented, Secure, Encapsulated, Well Performing, and it works.

Continue reading

Don’t Plan to Fail

SQL Server MVP Deep Dives 2, Chapter 3

Architectural Growth Pains – by Chris Shaw (B|T)

One of the things that struck me after I finished this chapter was how readable each topic has been. I realize this is only my third review, but I’ve read ahead a bit and it holds true for at least six of the MVP authors and I am guessing it will be true for all sixty. Chris Shaw pulls you into the possibly dry topic of database design with an anecdote of his days training to become a United States Marine. I grew up a military dependent (aka a Brat) so I related to Mr. Shaw’s story quite well. Even if he is a Jarhead. (Sorry Mr. Shaw, but my dad was a pilot in the US Air Force. Marines will always be Jarheads in my worldview.) Continue reading