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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
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)

Tuesday December 06, 2005
02:00 AM

I was so terribly wrong about databases

[ #27867 ]

Yeah, I've heard of Date and Codd. I've even read some of the former. I have felt moderately confident in my database knowledge. And then a recently published interview with Date has made it clear that I've committed the sin of listening to the majority rather than digging in for the facts. In particular, this passage simultaneously reveals my ignorance and makes me happy:

Object/relational DBMSs: To a first approximation, "object/relational" just means the domains over which relations are defined can be of arbitrary complexity. As a consequence, we can have attributes of relations--or columns of tables, if you prefer--that contain geometric points, or polygons, or X rays, or XML documents, or fingerprints, or arrays, or lists, or relations, or any other kinds of values you can think of. But this idea too was always part of the relational model! The idea that the relational model could handle only rather simple kinds of data (like numbers, and strings, and dates, and times) is a huge misconception, and always was. In fact, the term object/relational, as such, is just a piece of marketing hype ... As far as I'm concerned, an object/relational system done right would simply be a relational system done right, nothing more and nothing less.

There's quite a bit more where he tackles common misconceptions and how they contradict the relational theory. I believe I have another book to buy (though I'm still not certain how I feel about his objection to NULLs, but I'll read again what he has to say).

In other words, it turns out that much of what I've said about the relational databases was me being ignorant and being cocky about that ignorance. I'm more than a little embarrassed by this, but it's better that I just spit it out now.

And in other news, since Andy's already been announcing this, check out news.perlfoundation.org.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

I was so terribly wrong about databases 7 Comments More | Login | Reply /

 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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.