use Perl

• Database in Depth (Score:2)

  by davorg (18)

  Reading Date's book recently just reminded my of how much database theory I've forgotten since I was at college. He's right, of course, that the current set of popular database systems only implement a small part of Codd's original ideas[1] and that SQL is only a relational language in the very loosest meaning of the word.
  
  But, of course, we all need to get some real work done. And you're going pay the rent a lot easier if you're an expert on SQL that you are if you're an expert on Tutorial D[2] :)
  
  [1] If thi
• NULLs (Score:2)

  by Theory (10)

  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. Y
  • Re:NULLs (Score:2)

    by Ovid (2709)

    I just finished reading how to handle missing info without nulls [onetel.com]. 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 
    • Re:NULLs (Score:1)

      by jplindstrom (594)

      What's the difference between an "atomic operation" and a "transaction"?
      • Re:NULLs (Score:2)

        by Ovid (2709)

        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
• The difference between theory and reality... (Score:2)

  by djberg96 (2603)

  I wouldn't beat yourself up too much. He has a theory. A theory that he hasn't been able to implement, nor find someone else to implement, in 35 years. A theory that no commercial implementation has felt particularly compelled to follow to the letter, and which we've managed to do without.

  But, hey, at least we have a (partial) implementation of Tutorial D to replace SQL. That only took 35 years! Woot!

  This isn't to say that things couldn't be better. But writing about it and actually *implementing*
  • Re:The difference between theory and reality... (Score:2)

    by Ovid (2709)

    There's a possible equivocation on the word "theory". Date means theory in the scientific sense, not in the popular sense of "opinion" or "guess". The relational theory is well-grounded in set theory and predicate logic. This is a large body of mathematical theory which has been built upon since the ancient Greeks. Since even the crippled understanding of relational theory which most "experts" rely on is ignored by the masses, it's quite understandable to me that database vendors, following the herd, ar