Database Design: 101
In my line of work, I see a lot of legacy databases. We often tasked with converting them to something more modern. My #1 gripe with some of our junior programs in this task is not converting fields to a more appropriate data type when this takes place. Two examples that I come across often.
1. The boolean as anything but a boolean
This happens frequently when people are moving from an access database to anything else. Access wasn’t exactly friendly with boolean values (thou, it was possible to make a boolean field as an int(1) ). At any rate, most people who designed access databases used a char(1) where the values where either ‘Y’ or ‘N’. It’s an obvious mapping to a boolean. For whatever reason, people just leave these fields as the single character fields, instead of migrating it to a more friendly boolean field. So, that’s the first no-no of database design. Using anything but a boolean (or I’ll accept a bit field) for boolean values
2. The complete avoidance of enumeration fields
There are many cases when a field represents something like the status of an order: new, pending_payment, processed, shipped, complete. Often, I see these sorts of status as varchar fields. This is fine and dandy, except I have no idea what are acceptable values to put in the that column. I could do a select unique on it and hope that there is atleast one record representing each possible value, but that isn’t a reliable way to do it. One could argue the DBA would have documentation on what should go in there, or that the business logic would dictate it; but, most projects skip those points. Really, only the orgional programmer has any hope of remembering what can go in those fields, making them somewhat problematic to work with for future work.
In comes enumerations. Because you specify what the heck is valid in the field, you don’t have to guess what can possibly go in them. It’s actually their intended use. It also provides a form of feedback when you try to set that field to something your not expecting. Further preventing people from doing stuff like “New” vs “new” (which I have seen…).
grampa said,
November 27, 2008 @ 6:43 pm
Do not convert the legacy databases-just leave them alone and make up one that really works. Dump all of the access databases into the trash and make up one that really works and is up to date with the modern requirements. Ignore the boolean values and put in ones that you know will work with your modern database situation. Whom needs anything called “boolean?” If you do the above suggestions, then you will not have any cases when a field represents something that you do not want. Remember-there is no such thing as “business logic” any longer for sure. Remember that the original programmer has likely only copied something that he found on the web or perhaps on e-bay.
You will have fun with the above things, no matter what the values etc. might or might not be.
Also-if at first you do not succeed, then to hell with it.
gramp m and Maggykat
grampa said,
December 18, 2008 @ 6:30 pm
Well, today being the 18th of December-Happy Birthday, you old one. Hope that all is ok and you did something special for this special day
grampa m and the Kat, Maggy.
Got a kat yet?