Saturday, March 13, 2010
Banner

Announcements
Enterprise Data World - Karen and Rob are speaking

We Are Speaking at Enterprise Data World 2010

 
 

Discussion Group Login Minimize
Print  


Users Online Minimize
Membership Membership:
Latest New User Latest: Davidwp
New Today New Today: 0
New Yesterday New Yesterday: 1
User Count Overall: 2354

People Online People Online:
Visitors Visitors: 1115
Members Members: 0
Total Total: 1115

Online Now Online Now:
Print  

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 viewMonth view  Week viewWeek view  List viewList view  Print  

  Minimize

Copyright 2006-8 InfoAdvisors, Inc.