We get up early so that you don't have to. |
Database In Depth:
Relational Theory for Practitioners, $29.95
by C.J. Date
O'Reilly, 2005
208 pages
Examples in SQL and other notations
http://www.oreilly.com/catalog/databaseid/
I wanted to like this book. I really did. After all, it's by a noted expert in the field of databases, and it assures readers right on the back cover that "if you work with databases, you cannot afford to be without this book." And I myself have ve been among the chorus of authors who have assured readers that it's necessary to understand at least the basics of relational theory when designing a database, and to document where you diverge from theory and make compromises in the interest of living with real products in the real world. And yet...when you come right down to it, my life as a database designer wasn't really improved by reading this book. In fact, it very quickly went from "interesting" to "annoying."
The biggest part of my problem comes from the fact that Date, though clearly a very smart guy who could no doubt debate rings around me if we were to ever talk about databases in person, is also clearly one of that clique of people who knows that his way is right, that everyone else is wrong, and that's all there is to it. So he can come along and make perfectly outrageous statements such as "if you have any nulls in your database, you're getting wrong answers to some of your queries." Now, if he wanted to maintain that he could construct a pathological query that would give wrong answers in any database with nulls, he might have an argument (though even there, I suspect there is room for reasonable people to disagree). But the flat-out assertion that just about every database out there is somehow coughing up wrong answers on a regular basis is just silly, and makes him look like a jerk.
Sure, the math is interesting, and knowing how the original relational model has evolved mathematically is interesting too - at least if you're interested in the history of computing and in abstract mathematics. But does every designer of databases using products such as SQL Server, Oracle, or DB2 need to know this stuff to be successful? No - and again, that's obvious if you think about it; just look around at the number of working databases designed by people who don't have the relational theory memorized. I'm not afraid to say that I do not know all the finer points, and yet I have put together databases that do their job perfectly well. That's really all that I, and my customers, care about. Theoretical purity I can leave to the theoreticians without losing sleep at night.
Finally, there's some salesmanship going on here that also annoys me. After spending most of the book busting on the inadequacies of SQL as an implementation of the relational model, Date drops a few hints about the TransRelational (TM) Model, which always appears with the caps and trademark. Despite the name, it's not a new model but a new implementation technology which, we are assured, will bring us relational purity in real products at last. A bit of Web research shows that it's also super-secret and patent-encumbered and, so far at least, snake oil. If products using this technology come out, I'll be happy to take a look at them; until then, it's just one more promised silver bullet that we haven't seen yet, and I'll keep muddling along with my own slipshod SQL databases.