Re: A good book

paul c <toledobythesea_at_oohay.ac> wrote:
> I know nobody asked me but can't resist. What we want isn't always what
> we get. First, what we get from the RT is the certainty (with a
> faithful implementation) that results of the relops are logically
> correct, just like how we can depend on certain mathematical results
> when we know they are based on mathematical theory.

Okay. This seems pretty basic; the sort of thing that's just taken for granted... but if the IMS database didn't provide a valid specification and implement it faithfully (up to bugs, anyway, which get fixed when identified), then it certainly deserved to be replaced. :) I haven't used any OO database products, but I would be rather surprised if they did not provide specifications of reliable behavior.

> There are a few other
> things too, like normalization theory, which if ever an IT technique
> offered 'elegance', an 'ingenious and simple' way of arranging data to
> avoid redundancy as well as misleading conclusions, certainly qualifies.

Okay, fair enough.

> The criteria you want such as transformations and correctness are
> already possible (correctness as above and certainly transformations
> too), at least at a statement level, depending on what means by
> 'statement'. When you mention 'program correctness' that depends on
> what a program is defined to be and I'd agree that it is an open area,
> just as it seems to be when I read what people say about non RT db's.

Just to once again be entirely clear about this, my intention here is not to criticize databases or to advocate non-relational data store technologies. I would be a weak advocate indeed, since as soon as someone asks if I've ever used one, I would have to admit that no, I have not. I am not attempting to deny that important consequences arise from connections between relational database systems and the mathematical theory. I am simply asking what they are.

> and since then other notions such as transactions
> have been attached to RT, but I think they are not an intrinsic part of it.

I also get the idea that transactions are not particularly a part of the relational model. Clearly they are in some sense philosophically more compatible with declarative programming, versus most other concurrency management mechanisms. Nevertheless, I definitely don't see a clear connection between reliability mechanisms for databases and theory of relations.

> There is so much baggage involved with commercial IT that isn't directly
> part of RT that asking for 'one book' is a somewhat naive question.

Believe me, I don't actually intend to read only one book. If I'd asked for everyone's top 10 list, though, I'd be beyond the realm of possibility after a few responses. In reality, I will probably read at least a few books and papers, and I've enrolled in a graduate-level evening class at a local university in the fall semester which may or may not do a reasonable job of covering relational databases from a more conceptual level. We'll see.

As for Russell's book, it is again about relations, and not about how databases use them. It's looking like reading Codd's paper would be a good place to start for me, and then a couple of Date's books. And whatever the main text is for this class in the fall, I will probably read at least bits of that. I'm still thinking about Marshall's recommendation. :)

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation