Date's "Database in Depth" (was: Class::DBI etc)

[ti@lemonia.org]

   ----- Original Message ----
 From: Dave Cross

 [ ... ]

 [1] http://www.oreilly.com/catalog/databaseid/

 A lovely, lovely book.  A book which,regrettably, is still boxed up   on
the other side of the pond.  However, the book still expects   folks to
know the basics of normalization.

 It is a great book (see my review at
http://dave.org.uk/reviews/dbdepth.html) but it's not one that you  could
seriously expect to be read by everyone who just wants to build  a
database backend for their web site's forum.

--- end quote ---

Well. Encouraged by Dave's glowing review, I bought "Database in
Depth...", and read it. Well, some of it. I suppose l.pm is as good as
anywhere for somewhere to put my reactions.

I, personally, found it neither lovely, nor great. I'm kind of hoping
someone on l.pm will read this and say "Aha, the thing you're missing is
[...]", at which point the lights will go on, and I'll see what I missed
the first time round. (Yeah, I know, fat chance).

There is a lot in here about relational theory, but Date seems to have a
strong tendency to nudge against something interesting and then zoom off
in the opposite direction. For example, when he's talking in Chapter 1
about relvars: imagine a variable that contains the state of a table at a
point in time. He's suggesting being able to do things like this:

  people := people WHERE NOT name = "Thatcher";

or maybe even

  people_after_coup := people WHERE NOT name = "Thatcher";

Now, of course, you can't *do* things like that in relational databases.
The closest you'd get would be to create a temporary table (of appropriate
type), and put stuff in it, which is forcing you to work at a lower level
of abstraction, which is bad.

If you could do that, would you also be able to do this?:

if (people_after_coup == people) then
    # Attempts at overthrowing the government seem to have had no
    # effect at all
    throw_exception("Meet the new boss, the same as the old boss");
end;

(Yes, I know, that's a comparison rather than assignment operator).
As far as I can see, Date doesn't explore anything like this.

Too much of the book leaves me wanting to say, "Oh, come off it".

To pick the biggest problem first:
| 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.

How can you write about object-orientation and explicitly rule inheritance
as being out of scope? The most common problem with normalisation I've
seen in databases is when the designer is trying to deal with similar, but
not identical, data types. (Customers and staff are all people; they all
have names, and contact phone numbers, and such, but staff will then to
have other data in addition). I don't believe Date mentioned anything
about encapsulation, either.

There's a fair bit about SQL tables being bag- rather than set-oriented:
you can have identical rows. I need no persuading that this is exceedingly
bad practice, but to do that, you'd need to declare tables with no primary
key. Does anyone do that? (Suppose you applied a numeric/serial primary
key, but nothing else? What you have is then valid under the relational
model, but may well make no sense, depending what the numeric key means in
practice).

Why would you want to nest tables within tables within tables?

Why are pointers verboten? Are Oracle's unique-across-the-whole-database
object IDs pointers? What about serial primary keys?

And then there's the trouble with NULLs. "If NULLs are present, we're
certainly not talkinga about the relational model... the entire edifice
crumbles, and all bets are off"!, writes Date, apocalyptically[1]. He does
expose some serious weaknesses in three-valued logic, but is extermination
of NULLs the right answer? What happens to the results of outer joins if
there are no NULLs in the relational model? And if NULLs are so obviously
disastrous, what sort of fool is Codd?

ACID transactions. Transcations should not be the unit of consistency,
Date says. This is a pity; having outlined highly orthogonal measures to
allow (for example) constraints to be defined and enforced on VIEWs, as
well as TABLEs, one can quite easily imagine constraints existing which
would require updates to multiple tables in order to move the database
from one consistent state to another. Again, I've no idea what we're
supposed to do in that case.

And then there's the point about tables not being flat, but N-dimensional.
Why see your tables as a grid of rows & columns, when you can regard each
record as a point in N-dimensional data space? BECAUSE YOU CAN WRITE IT ON
A PAGE, OR A WHITEBOARD, AND IT DOESN'T MAKE YOUR BRAIN ACHE, *that*'s
why, and it is, in any case, entirely subjective; either model can be an
accurate representation of the data in a relation.

I find it very difficult to regard this as a book for practitioners at
all. Too academic[3], too mathematical, no real-world[2] examples at all,
too much focus on areas which no practitioner can actually change. I
daresay MySQL's detractors would *love* to see it rebuilt using
Tutorial-D, because it would eat a vast amount of programmer time, confuse
everyone, and probably sink MySQL.

The book has, of course, no mention at all of object-relational mappers,
which seem to me like a very promising area of development for enabling
richer, better, faster database development.

I await flames, a stony, bewildered silence, or a return to the usual
topics of building pie-making opcodes into Parrot...

ti'

[1] I am reminded, oddly, of Dionysious Lardner's claims that, if a train
in Isambard Kingdom Brunel's new tunnel's brakes failed, it would emerge
at over 100 mph, a speed at which passengers would be unable to breathe.
He'd neglected to account for air resistance, and made up the bit about
being unable to breathe. Full story in LTC Rolt's biography of IK Brunel.

[2] By "real world", I mean not "involving pots of money", but "involving
significant amounts of data, and the sort of problem you'd actually use a
database to solve". Finding examples which are simple enough to teach with
-- yet complex enough to give the reader a sense of what the point is --
is a difficult task, and not one this book succeeds at.

[3] ... which it pains me to say, because theory and practice should
inform each other, rather than being incompatible, polar opposites.