Cookies help us display personalized product recommendations and ensure you have great shopping experience.

By using this site, you agree to the Privacy Policy and Terms of Use.
Accept
SmartData CollectiveSmartData Collective
  • Analytics
    AnalyticsShow More
    sales and data analytics
    How Data Analytics Improves Lead Management and Sales Results
    9 Min Read
    data analytics and truck accident claims
    How Data Analytics Reduces Truck Accidents and Speeds Up Claims
    7 Min Read
    predictive analytics for interior designers
    Interior Designers Boost Profits with Predictive Analytics
    8 Min Read
    image fx (67)
    Improving LinkedIn Ad Strategies with Data Analytics
    9 Min Read
    big data and remote work
    Data Helps Speech-Language Pathologists Deliver Better Results
    6 Min Read
  • Big Data
  • BI
  • Exclusive
  • IT
  • Marketing
  • Software
Search
© 2008-25 SmartData Collective. All Rights Reserved.
Reading: Anith Sen: Five Simple Database Design Errors You Should Avoid
Share
Notification
Font ResizerAa
SmartData CollectiveSmartData Collective
Font ResizerAa
Search
  • About
  • Help
  • Privacy
Follow US
© 2008-23 SmartData Collective. All Rights Reserved.
SmartData Collective > Uncategorized > Anith Sen: Five Simple Database Design Errors You Should Avoid
Uncategorized

Anith Sen: Five Simple Database Design Errors You Should Avoid

KarenLopez
KarenLopez
3 Min Read
SHARE

Anith Sen, an 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 usual 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 …

More Read

A Very Good Year
Good, Bad & Iffy
A comment on OffShoring
Sustainable Execution – 10 rules for survival
Transform 2012 – Moving Business from Survival to Thrive Mode



Anith Sen, an 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 usual 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.

Technorati Tags: database design,data modeling,antipatterns,errors,entity attribute value,lookup table,check constraint

TAGGED:data quality
Share This Article
Facebook Pinterest LinkedIn
Share

Follow us on Facebook

Latest News

sales and data analytics
How Data Analytics Improves Lead Management and Sales Results
Analytics Big Data Exclusive
ai in marketing
How AI and Smart Platforms Improve Email Marketing
Artificial Intelligence Exclusive Marketing
AI Document Verification for Legal Firms: Importance & Top Tools
AI Document Verification for Legal Firms: Importance & Top Tools
Artificial Intelligence Exclusive
AI supply chain
AI Tools Are Strengthening Global Supply Chains
Artificial Intelligence Exclusive

Stay Connected

1.2kFollowersLike
33.7kFollowersFollow
222FollowersPin

You Might also Like

Missed It By That Much

6 Min Read

#19: Here’s a thought…

4 Min Read

The Quality Gap: Why Being On-Time Isn’t Enough

6 Min Read

Not So Strange Case of Dr. Technology and Mr. Business

9 Min Read

SmartData Collective is one of the largest & trusted community covering technical content about Big Data, BI, Cloud, Analytics, Artificial Intelligence, IoT & more.

AI chatbots
AI Chatbots Can Help Retailers Convert Live Broadcast Viewers into Sales!
Chatbots
ai chatbot
The Art of Conversation: Enhancing Chatbots with Advanced AI Prompts
Chatbots

Quick Link

  • About
  • Contact
  • Privacy
Follow US
© 2008-25 SmartData Collective. All Rights Reserved.
Go to mobile version
Welcome Back!

Sign in to your account

Username or Email Address
Password

Lost your password?