Common Databasing mistakes{2}

by Daniel M
The article that i read was about the common mistakes that are made when people are designing and building databases. The article talks about how people need not rush into the planning aspect of the database in order to just get it done. The next big mistake that people make is in the naming of objects. The article talks about how important consistency is when you are naming objects and how important it is that you make the name something that anyone can recognize and understand why you named it that. Defining is another common mistake when people are building databases. the article says that you need to define all of your table, columns, and relationships so that you can figure out what you did later on. the last important thing that is too often overlooked is to make sure you do ample amount of testing of your database before you say it is done. The article talks about how when time starts to get short on a project the first thing that people tend to not do is to test the database well enough before they release it.

I found this article interesting because i think that all too often people seem to overlook the fundamental steps of most things they do. I think that for me it was good to read this article and learn some of the common mistakes that people make when they are databasing. I think that the documentation and naming of the objects, columns, rows, etc. are super important because it allows someone else to come in and see exactly where you are and it also allows for someone to be able to pick up right where you left off if need be.

I also felt that it was interesting that lack of testing was in the article. i figured that would have been one of the things that most people spend a decent amount of time on but the article made very good points as to why there would be a lack of testing before releasing the database. I think that time constraints is probably the most common reason why people don’t test before they release. The other reason for lack of testing was that the programmer looks for specific problems and fixes the big problems but doesn’t look into the small problems that may come up later, or they just overlooked a problem. I think think this article gave me a good base to make sure i don’t make the same mistakes.



Davidson, L. (2007, February 26). [Web log message]. Retrieved from