With the previous post on the fourth pillar, I have reached the “end” of the design posts.  To review, these were:

• Coherent – cohesive, comprehendible, standards based, names/datatypes all make sense, needs little documentation
• Normal – normalized as much as possible without harming usability/performance (based on testing)
• Fundamentally Sound – fundamental rules enforced such that you don’t have to check datatypes, base domains, relationships, etc
• Documented – Anything that cannot be gather from the previous four is written down and/or diagrammed for others

When you are looking at a database that you have NO idea what it does, or why it exists, these things I have so far outlined will be the sorts of things you notice first. If NOT(normalized AND understandable AND data protected AND documented) = TRUE, then you will feel it and really hope that you are an hours based contractor with your highest rate and a set time to pack up and head elsewhere richer than a .  If the opposite is true, being an employee for that company is where you want to be.

Looking back, one thing stands out to me as a possible (reasonable) concern. I didn’t include anything about “complete”.  By the time my next edition of “Pro SQL Server 2008 Relational Database Design and Implementation” rolls around, it might.  However, my initial thinking was that these were characteristics beyond the basic “it must at least work” benchmark that should be obvious to any semi-logical human being (which I suppose limits the gene pool, but at least most readers of my book who don’t misunderstand the term data model as a social activity will meet that requirement). I sort of hope it goes without saying to those folks that a database cannot be a good database without it serving the needs of the users. The only thing I am trying to point out in these pillars is to ascertain how cleanly the database does that task.

I also think that I might do some rearranging to make Normal and Sound Theory as the foundation and just have six pillars.  Either way, things will change.

For example, if you were modeling a time entry system, no matter how normalized, understandable, data protected and documented your system was, if you failed to capture who was entering time and the employees never got paid, your database would suck.  In fact, I would go so far as to warn you to expect a large group of people at your door with pitchforks and torches ready to give you an alternate meaning to the term “perforated colon” or at least a crash course in database design/implementation.

The thing is that anyone building a system to capture employee’s time and getting them paid would do a certain set of things, even if the entire system was done on paper. The fact is, rare is the case that a system is created that won’t minimally do the task that was originally asked for in some reasonably decent manner. In fact, this can, as a person who wants to get it done right, be your biggest enemy.  Getting it done well can easily take a back seat to just getting it done.  Worse still, there is some truth to the logic to this statement.  As the old saying goes:

Better is the enemy of good enough
Admiral of the Fleet of the Soviet Union Sergey Georgiyevich Gorshkov

But the problem with that saying is in the interpretation. What is “good enough”? To me, this lack of a definition of good enough is what derails a lot of projects where this is the sentiment. If you don’t define “good enough” as being a solid platform for growth and usability, this is pretty much a half truth, and a half truth is far more difficult to deal with than a complete lie. 

And then she understood the devilish cunning of the enemies’ plan. By mixing a little truth with it they had made their lie far stronger.
C. S. Lewis, The Last Battle

As the architect of a system, just getting it done is NOT the goal. It is a very important step along the way to the actual goal, but it is not the goal. Malleable software that can grow and expand to meet the needs of the users now and in the future is the goal that serves your customers best. The cost of creating and managing software over months and years is often a lot more than is initally thought. The cost of having a human do the work on paper and filing cabinets can be more efficient and cheaper than poorly written, hard to manage software.  Too often computers just turn a bunch of paper forms into bits and bytes rather than streamlining a process to make the computer do the work for you.  Sometimes it is just protecting the jobs of others that causes this, but the fact is, eliminating a job of a person who pushes a button over and over every day will allow someone to be hired to do actual work (even the button pusher!) that can add to the bottom line, not simply waste resources.

The pillars were conceived a “catch phrase” to help think about how we can ease the process of getting the system built, created, and eventually maintained in a manner that helps the eventual product be useful for years to come, and in the process help you to become a respected member of your team, not the one who is talked about as a “good riddance” once you have finally left the company.