Hey, did you catch that redirect? The Toad World URL is now community.toadworld.com. Don't worry -- you'll still find all the same great content here (and more on the way). We're just in the process of giving our Toad World site some well-deserved love. Stay tuned for some more updates coming this way.
Meanwhile, enjoy community.toadworld.com.
Times change. In the good old days “good” relational database design was rather straight forward, there were simply tables with columns and rows plus rather simple indexing options. Thus database designers merely had to generally employ just two fundamental “best practices”: sensible table normalization and minimal, effective indexing. Table normalization (when not overdone) was an important but quite often misunderstood paradigm. Database designers generally presumed that normalization accomplished five primary goals:
The problem was most people also assumed that the first goal was key in order to reduce the overall size of the database since (in the past) disk was expensive. In fact the first goal was not a goal at all, it was merely a side-effect required to accomplish the second goal. Hence the general misunderstanding. Nonetheless one could review a database design and judge/debate its normalization level rather easily.
Indexing on the other hand was fairly well understood and generally suitably implemented since in most cases there were relatively few indexing factors:
Then times began to change. First index design became far more complicated due to numerous and in some cases novel new database features related to indexing. Indexing options now additionally include the following factors:
So what was once easy is now quite challenging. And since indexes often play a key role in SQL explain plans, indexes are now one of the hardest things to both effectively and efficiently design.
But what really obscures “good” relational database design are all the new industry directions related to data. Over the past decade or so we now have many more influencing factors:
The point is that now table design is far more subjective based on the need at hand and requirements. I would not presume to debate anyone’s database design with so many factors, because the right answer would now entirely depend on what paradigm is being used and for what purpose or goal. There now is no wrong answer.
Thus we’ve had a complete reversal of database design challenges – what once was easy (i.e. indexing) is now extremely hard, and what once was fairly less subjective (i.e. table design) now requires far more contextual insight. So while in the past I could fairly easily identify a bad database design, today I would not presume to make such a call. So what is “good” database design? It literally all depends.