Database Design Always Matters
You can spend a little more time upfront or a lot more time later
Issue: 12.2 (March/April 2014)
Author: Craig Boyd
Author Bio: Craig Boyd is currently an Oracle DBA for a well-known national retailer. But in his 17 years of IT experience, he has been everything from a PC Technician, iSeries System Administrator, iSeries Programmer, Sr. Technical Lead, and Data Modeler. He lives in the great state of Texas with his wife and two kids.
Article Description: No description available.
Article Length (in bytes): 18,264
Starting Page Number: 66
Article Number: 12213
Related Web Link(s):
Excerpt of article text...
We have all done it and had it done to us. We need a little "quickie" solution to hold some data for just a short period of time. So we throw together a couple of tables on a database within the company somewhere and crank out the most ugly and basic interface just to get things running. A couple of months go by and we are seeing a little more use for the thing. So, we add a couple of columns where they really don't belong, but we don't want to spend a lot of time on this yet we do it anyway. Later, someone peaks over our shoulder and says "Hey, can I connect to that too? I could really use that information for some of my TPS reports". Before long lots of people are using it and now they want to do more with it. Only they can't because the database design is terrible and needs to be completely redone. This means a complete redesign and rewrite of the code. Or another and more likely scenario is that we inherit the aforementioned database and now we are the ones stuck having to work with it.
reallymeans is that database design is alwaysimportant! I am not suggesting that we have to design each and every database we create to be able to scale to thousands of users across multiple server nodes, but I am saying that we do alwaysneed to follow some basic database design rules. We are going to use a database that a friend of mine asked me for help with as our case study so this will be more than an academic exercise.
Here are the steps we will be going through:
1. Figure out the current state of the existing database
2. Identify the existing design flaws and determine how best to fix them
3. Gather requirements for the changes
...End of Excerpt. Please purchase the magazine to read the full article.