As a data architect, and writer on the same subject, I am completely entrenched in learning and applying the discipline of normalization. When I set my course down the road of great database design, my motto is “Fifth Normal Form or bust<\/i>“, even if it takes months to finish the design for just a few tables (and, of course, to make sure every table and column is meticulously named). Not much gives me greater pleasure than the beauty of a database that has been honed to a high degree of normalized perfection and that, to the amazement of the many detractors and doubters, also performs magnificently.<\/p>\n
If this sounds like one of Lewis Carroll’s stories, there is good reason for it. The reality is that I don’t live in Wonderland, and rarely get time to design anything, much less everything, in meticulous detail. My average project tends to fall into one of two categories<\/p>\n
My normal workday, as a result, most closely resembles a typical episode of the TV show, Junkyard Wars…”Contestants, you have just 10 hours to build a fully-working dragster from the contents of this junkyard.”<\/em> My favorite team welded together an old motorcycle and a rusty golf cart and went flying down the track. Their solution would never work long enough to survive the complete drag racing season, but it survived 2 trips down the eighth mile. They knew for how long their solution would be used, but most software built like this, with a planned expiration date, usually last years longer than expected.<\/p>\n \n Many project are like this; get it done quick. The best theoretical solutions need not be posited; your deep and hard-won knowledge of advanced “internals” is of little good to you here. Practical is what is required. When a manager says “as soon as possible”, they don’t mean “as soon as you can reasonably arrive at the optimum database design and then build a proper solution with stringent application of sound programming principles<\/i>“. They mean “why haven’t you got something to show me, already?<\/i>“<\/p>\n \n The oft-heard battle cry from management is that “Better is the enemy of good enough”; true, but in the wrong hands, very dangerous. Too often, the definition of “good enough” is taken to mean something works to the point that the manager can check a box, no matter the implications to the future user or maintenance workers.<\/p>\n \n