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

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.
  • by Theory (10) on 2005.12.06 10:55 (#45009) Homepage Journal

    I haven't got to his criticism of NULLs in the book, yet, but I have my own ideas about why they suck. First of all, a NULL is supposed to mean "unknown." The problem comes when you need to represent "known, but empty." This is fine for character fields, where you can set an empty string (Larry calls it a "null string"), and it not null but has no real value, either. But how do you do that for, say, integers? For dates? You could use 0 for integer, but that's an actual value. You could use '0000-00-00T00:00:00' for the date, but that's an actual date (Happy Birthday, Jesus!). So what do you use for "the value is not unknown, it's intentionally left blank"? SQL gives you no way to do that.

    I've been meaning to blog this for a while, but what the hell, might as well just say it here.—theory
    • I just finished reading how to handle missing info without nulls []. It looks really long, but there's a goof up in the PDF and the slides have been duplicated. The actual talk is very short and then there's a step-by-step walkthrough of the D-like query they use to get the answer.

      One potentially unsatisfactory approch is to use an extra column to denote the type of null information of another column.

      id   name    salary  salary_reason
      1    Mary    20,000 

      • What's the difference between an "atomic operation" and a "transaction"?
        • A transaction may contain many atomic operations and becomes, itself, an atomic operation. However, the database itself may be in an inconsistent state during a transaction. The relational theory outlined by Date requires that no atomic operations allow the database to be in an inconsistent state. For example, let's say you have an employee relation (table) and salary values are moved into separate tables defining them as either "unknown" or "unemployed" (for previously null values) or "salary_amount" fo