Geeks With Blogs
The Lanham Factor The (ir)rational thoughts of a (not-so)mad man

In a recent blog post I took a stand for natural database keys versus artificial keys.  Many thanks to Sean Smith for his excellent feedback regarding that topic.  As a result, I am having a slight change of heart about that topic.  Specifically, I am looking at it from two perspectives including identification of natural keys and, secondly, who should make the final decisions.  I will discuss each of these in turn.

The example I used in arguing for natural keys was email address.  Sean Smith made several good arguments against this (please read that entry for more information).  One thing that stands out about his comments is that although globally (actually, within the solar system) unique, email address may actually not be a primary key.  When modeling the business and, subsequently, the requirements, the analyst has the task of identifying key fields in the business entities.  As part of analyzing the business and requirement models, it's possible that even the most experienced analysts will inappropriately identify key attributes.  As a result, these may get mapped to the data model design inappropriately. 

The moral of this part of the story is it is extremely important to get multiple perspectives.  Someone else simply saying "Hey, Mr./Ms. Analyst, there is no requirement that the email address be for a specific person or role.  It could be a group address."  This is an example of the importance working as a team, conducting peer reviews, and most importantly, do NOT get caught up in modeling for the sake of modeling.  I can't believe it's me writing this but it's true.  I push for using natural keys such as email addresses because it is “correct.“  That doesn't necessarily mean it's the right thing to do.  It is important to sometimes make concessions in the most “pure“ modeling efforts to improve the overall design and, subsequently, implementation of the software system.

My second perspective is related proper role-assignment.  In the situation described in that article, Sean Smith (once again) showed how implementing a natural key is not necessarily the best approach for database performance and scalability.  This re-emphasizes to me the importance of having proper role assignments and tasks for those roles.  In my situation, it would have been best to have a Database Administrator review the data model before implementation.  That's right, the DBA may have a completely different perspective than the Data Engineer.  This is especially true if the data engineer is also the analyst. 

To help resolve this issue, not only must proper role assignments be used, but proper development processes are also important.  Again, not just having a DBA involved but structuring the involvement of various team members at appropriate points in the project.  So combining the right roles, which actually equates to the right skill sets, with a well-defined work breakdown structure containing appropriate, structure peer reviews will promote an environment wherein the best design decisions are made which may or may not be the most pure.

Posted on Saturday, December 3, 2005 4:36 PM SILC - Solution Implementation Life Cycle , Cutting Code | Back to top

Comments on this post: The Right Tool for the Right Job

# re: The Right Tool for the Right Job
Requesting Gravatar...
FWIW here's a link to a comment I posted back in the day.
Left by Brian on Dec 05, 2005 9:09 AM

Your comment:
 (will show your gravatar)

Copyright © Brian Lanham | Powered by: