Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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
  • 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

    • 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 

      • 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

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

    • 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