THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Louis Davidson

The phases of database design

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.

Published Tuesday, December 16, 2008 11:43 PM by drsql

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Paul Hunter said:

Thanks Lousi.  Agile is a development practice and not a requirements or design practice.    You are 100% spot on with your statement "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"

Anologies between building a house and software development are apprpriate.  People are very specific about he number of bedrooms, kitchen features and space in the living areas (all the major features of the product) but are less focused on plumbing, wiring, ventilation and foundation (all the other stuff that makes the application work).  You must plan, specifiy and think about what you want.  You just can't make it up as you go along.

I'm glad we don't do the space program with agile practices.  It would be tough to get to Mars and then figure out you can't get back because of the lack of planning.

December 20, 2008 12:05 PM
 

drsql said:

That is a great comment: "I'm glad we don't do the space program with agile practices.  It would be tough to get to Mars and then figure out you can't get back because of the lack of planning."

But isn't part of Agile just in time requirememnts gathering too?  Figure out the bite you want to take and then figure out how to get there? My agile experience has been limited to people that didn't really know how it was to be done (myself and a lot of people I hope don't read comments included).

December 21, 2008 12:45 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Links to my other sites

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement