Thursday, September 02, 2010
Banner

Announcements
 

Discussion Group Login Minimize
  


Users Online Minimize
Membership Membership:
Latest New User Latest: dnewdick
New Today New Today: 0
New Yesterday New Yesterday: 0
User Count Overall: 2395

People Online People Online:
Visitors Visitors: 1203
Members Members: 0
Total Total: 1203

Online Now Online Now:
  

Archive Minimize
Partners Minimize

InfoAdvisors partners with

 
embt.png
 
 
Microsoft
Sybase
Telelogic
 
We can help you evaluate and successfully implement our partners' products
 


Welcome... Minimize

Welcome to InfoAdvisors' website dedicated to information technology processes.  You'll find subscriber-written articles on UML, data management, data modeling, process modeling, ITIL, information governance, as well as materials to help you improve your information management resources.



Karen Lopez: Musings on Data, Process, and Architecture Minimize
Oct 19

Written by: Karen Lopez
Monday, October 19, 2009 2:11 PM 

Anith Sen, A SQL and database design guy based in Tennessee, has a well-written blog entry over on Simple-Talk about database design errors.

What I liked about Sen’s post is that he has taken great care to show data and table structures that appear to have some real world complexities to them while still being simple examples.  I don’t know many bloggers who do this.  Most examples seem to be slathered with “PersonName”, “ZIPCodes” and “tbl_EntityName” data modeling errors that distract me from the points being made.  He includes data, table structures, and SQL.  Kudos.

The 5 errors discussed are:

  1. Common Lookup Tables
  2. Check Constraint Conundrum
  3. Entity Attribute Value Table
  4. Application Encroachment on DB Design
  5. Misusing Data Values as Data Elements

Personally, I don’t agree that all of his examples are errors, per se, but I do agree that they are anti-patterns for most uses.  My usually mantra of “all design decisions come down to cost, benefit, and risk” should apply.  If we take, for instance, his example of statuses in a common code table, he seems to imply that all generalizations of status are inappropriate.  I do agree with his reasoning as to why the pattern is costly, but I don’t see any reason why all statuses need to be in separate tables.  I don’t believe all codes should be in one big table, either.  Hence, my invocation of cost, benefit, and risk still applies.

A great article, though. Well worth your time to read and absorb.

Tags:

Your name:
Your email:
(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Security Code
Enter the code shown above in the box below
Add Comment   Cancel 
InfoAdvisors Calendar List Minimize

 Month view   Week view   List view    

  Minimize

Copyright 2006-8 InfoAdvisors, Inc.