Before I get started with the pillars of a well built database, I want to reply (in long form) to a comment on the last post. I see the phases of the project to have five distinct phases (again trying to make memorable lists that an stick in your mind):

• Requirements – The process of extracting what needs to be done from the mind of the people you are going to be implementing for
• Design – Preparing for implementation by getting a blueprint of what you are going to build
• Implementation – The act of creating objects to store, protect and manipulate data
• Tuning – Making the code work fast enough while not losing any fidelity.  In other words, if building a program to add 1 + 1, the faster you can get the answer 2 the better. If you can’t guarantee to get back 2 every time you execute it, it doesn’t matter how fast you can get the answer.
• Maintenance – The dreaded part of the process, where the developer or support people make changes to the system to meet new needs.

I focus most of my writing in the design book on the Design and Implementation phases of the project. Requirements are usually done by the business analyst role, and tuning and maintenance are follow on processes that happen once you get deeper into how the system is actually used.

Now don’t take this as if I am one of the elitists that don’t consider the reality of usage in the design. I feel that it is a building process and if you get requirements right they will at least hint at usage (and will more likely be pretty specific about what you need to test for), the design will consider tuning in some ways, implementation will produce a flexible product that can be tuned.  Once you have a well built solution you will then have less need for tuning, but you will have your solution in a form that can easily be tuned, and will be very maintainable.

If you are an agile bigot, you might be screaming at the screen “Waterfall! NOOOOO”.  Well, don’t.  I can’t hear you anyway. I prefer a heavy dose of requirements up front, but that and any other phase can be split up into smaller phases.  But the fact is you have to figure what you want to do (requirements), how you are going to do it (design) and implement the solution in that order, even if you don’t do everything at once. The only downside with agile techniques is that you need programmers with good foresight.  You might be building a program to add values between 0 and 10 to other values between 0 and 10 in the first phase, but later you need to add all real numbers.  You could write an adding program for 10 values like:

case when @parm1 = 0 and @parm2 = 0 then 0
        when (@parm1 = 0 and @parm2 = 1) or (@parm1 = 1 and @parm2 = 0) then 1
        …

But you certainly cannot use this methodology for larger numbers..And you wouldn’t want to for smaller ones. Creating over simple solutions can be a downfall of an iterative approach when you have no visionary developers.