Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Wednesday April 11, 2007
03:25 AM

Things You Don't Want to Hear

[ #32963 ]

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)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • What's the fields name? I can top it.

    A field called MfgPartNumber. What do you think is in that field? Well, sometimes, a mfgs part number for a part. Sometimes a prefix. Sometimes empty, but on private label parts only. Sometimes, a brand number.

    • 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!

      • Randal L. Schwartz
      • Stonehenge
      • 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).

    • Except for the gratuitous NULL, that doesn’t seem too bad?

      • 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.

      • 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

        • 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.