More signs that most programmers should never be allowed to touch databases:
"Oh, that field in the database can contain a NULL, a 1 (one), or the string 'billing'".
(Mind you, I'm reasonably certain the person who said that is not responsible for that dreck)
Re:Bah. That's nothing.
merlyn on 2007-04-11T17:55:32
This is often what happens when the DBAs don't respond fast enough to developer requests or make them fill out too many forms.
The programmers just "work around" them by repurposing some other unused field.
DBAs: take notice!
Re:Bah. That's nothing.
chromatic on 2007-04-11T18:48:30
Lawyers, DBAs, and system administrators sometimes tend to think that everyone else works for them, not the other way around. (I've been two of those three at various points in my career.)
Domain: credit cards. Field: "Status" (or thereabouts). Range of values: "O" for open, "C" for closed, "I" for inactive, NULL for open or status unknown (have to check other variables to be sure).
Re:My favorite
Aristotle on 2007-04-11T17:00:16
Except for the gratuitous NULL, that doesn’t seem too bad?
Re:My favorite
dagolden on 2007-04-11T18:26:51
It wasn't too bad once we figured it out. The formal documentation only had the alphabetical codes and NULLs were about 50% of the dataset.
Re:My favorite
Ovid on 2007-04-11T21:02:27
Well, if it's MySQL it's bad since that data should probably be an enum and MySQL (particularly older versions) will insert an empty string if you get the enum value wrong. However, even then I wouldn't use an enum. That should probably link to a separate "cc_status" table or something like that. You can then more easily insert new statuses, add human readable descriptions for each status (often with enums I see human readable versions hard-coded in the program), and you don't have to worry about changing the data type for a column if a new status appears. It's far better to change the data than the data description!
Re:My favorite
Aristotle on 2007-04-12T21:19:33
You can then more easily […] add human readable descriptions for each status (often with enums I see human readable versions hard-coded in the program)
The database is a terrible place to put any string that might be subject to i18n.
I agree with the rest of your points.
