Database Design Mistakes

by Hieu H
A poorly designed database can lead to many problems down the road. It may not be apparent at first, since there is very little data, but as the database grows, you may start to experience inefficiencies and poor performance. Some of the seven most common mistakes that database professionals make include not spending enough (or any) time on documentation, little or no normalization, building before designing, improper storage of reference data, not using foreign keys or constraints, not using naming standards, and improperly choosing primary keys.

In chapter 2, we learned the basics of modeling rules in database design. It is important for us to define business rules and definitions during the design phase so that we can keep the database consistent. We also learned about primary keys and when and how to choose them. It was good to see the article reinforce the many topics that we covered. There were some items that we haven’t discussed in class yet, such as normalization (week 4) and reference data, but I’m sure that the article exhibits the same point of view.

When I just started working with databases and creating my own, I often built the database as I went along. I would add tables, attributes and relationships as they were needed during the coding process. This often led to making numerous database structure changes and many columns of duplicate data. I agree with the article that one should spend the time to design the database before actually building it to avoid such headaches. Documentation also helps as reference in future troubleshooting sessions.

Tiret, J., (February 16, 2010) Seven Deadly Sins of Database Design. Retrieved October 5, 2012 from http://esj.com/Articles/2010/02/16/Database-Design-Sins.aspx

3 thoughts on “Database Design Mistakes

  • October 7, 2012 at 12:01 pm
    Permalink

    I completely agree with you. If you do not spend the time and put the effort into laying out your database whether on paper or in a program you can cause a lot of issues later on. Causing you to have to possibly rebuild or change certain sections of your database and then you can lose the integrity of your data as well. Not to mention the possible downtime that your database could inccur. Good article, it definitely reinforces the importance of designing and planning before building.

  • October 7, 2012 at 7:12 pm
    Permalink

    Great read, design before doing is definitely a solid start of doing anything. Having a complete map of what is gonna be build will greatly reduce the mistakes and enhance the fluency. So there is no exception in database world too. Well and accurately organized data will not only reduce the cost but also improve the efficiency.

  • October 7, 2012 at 11:52 pm
    Permalink

    I agree with spending as much time needed in designing and analyzing all the different aspects of the database to avoid issues at the end such as overspending, delaying deployment, and also facing poor database performance. It is important to have good scope of the project and have a good project manager to lead you the right direction to avoid iteration that may cause database integrity problems and consistency.

Comments are closed.