10 Common Database Design Mistakes

by Eric H
Its hard when design a database, but in the article it pointed how 10 of the common mistakes people make when design the database:
1. Poor design/planning
2. Ignoring normalization
3. Poor naming standards
4. Lack of documentation
5. One table to hold all domain values
6. Using identity/guid columns as your only key
7. Not using SQL facilities to protect data integrity
8. Not using stored procedures to access data
9. Trying to build generic objects
10.Lack of testing

When designing the database spending enough time and thinking it through it critical, and not to ignore proper planning phase just to get it done, It will waste more time to go back and fix a problem than just spend the time and plan it correctly in the first place. Secondly, do not ignore normalization. normalizing your data is essential to good performance and ease of development. Naming in database is always very important, keeping a consistent naming ruling when making a database can save a lot of headache down the road. Leaving definitions on its tables, columns, relationship, and even default and check constraints, making it clean to everyone how a function is tended to be used, it will be useful when going back to make changes or fix something (Davidson, 2007). Putting multiple tables into a single “catch-all” table simplify the design, it keeps a consistency in the whole design. The author pointed out another useful tips is each tables should have a natural key that means something o the users, and can uniquely identify each row in the table. All fundamental, non-changing business rules should be implemented by the relational engine. the base rules of nullability, string length, assignment of foreign keys, and so on, should all be defended in the database (Davidson, 2007). Another tips is stored procedures are your great, use them whenever possible as a method to insulate the database layer from the users of the data. Also we should avoid coding very generic objects, such as ones that take a table name and twenty column names and values pairs as a parameter and lets you update the values in the table(Davidson, 2007). A very important tips is to test your database, by testing it you will find out most of the problem and flaws in the database.

This relates to our class lectures because it points out the common mistakes people makes when designing and building a database. I learned now to rush the design phrase just to get things done fast, because i could be wasting more time by doing so. and being consistent in naming and defining the relations. And also to test the database when its done.

Davidson, L. (2007, February 26). Simple-talk. Retrieved from http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/

4 thoughts on “10 Common Database Design Mistakes”

  1. After reading your article, it reminds me the recent search that I have found “Codd’s 12 rules” which is the measurement for evaluating a rational database system. I also agree that any careless mistake we make while designing a database may require a lot of time to fix it later on. Nevertheless, mistakes always occur. Therefore, testing databases become the essential part at the end.

  2. Don’t take the easy road out. Just put in the necessary time now to get the database working efficiently and then later on you won’t have to worry about fixing that one little mistake that lead to all these problems. This article was very informative in that it provides readers with popular types of mistakes designers encounter. I have to agree with Polun that mistakes will always occur but if you fix then now instead of waiting then you will be saving yourself a headache later on.

  3. Interesting read. Even though a lot of the mistakes can be ignored with common sense/not being lazy, it is good to be reminded of these things. It’s also pretty cool how business rules apply to technology such as databases.

  4. Great article, I guess problematic things will tend to pile up in the end of the design phase if these mistakes occur and then get forgotten which would hurt the developer and the organization in the long run.

Comments are closed.