NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
My favorite (Score:1)
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).
Reply to This
Re: (Score:1)
Except for the gratuitous NULL, that doesn’t seem too bad?
Re: (Score:1)
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: (Score:2)
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 changin
Re: (Score:1)
The database is a terrible place to put any string that might be subject to i18n.
I agree with the rest of your points.