Re: foundations of relational theory?

byrmol wrote:
> I still haven't learnt anything here, that might be just me, but I
> doubt it. [snip]
>
>
> But I have come to some conclusions.. (And this is not meant to be a
> troll)
>
>
>
> 1) MV/PICK is not a data model by any accepted definition.
Granted; but that's mostly because there has been no study of. It is more of a data handling mechanism than a data model.
>
>
> 2) The logical/physical distinction in MV/PICK is unidentifiable.
Not entirely, but much more than in a model that starts from a mathematical theory.
>
> 3) Every time anyone says the word theory, the MV/PICK people say
> practise, which tends to justify statement 1 & 2.
Ok.
>
>[snip]
>
> But I am huge advocate of the relational theory of data for 2 valid
> reasons and 1 selfish reason..
>
>
>
> 1) It has a general theory that has gone unchallenged for hundreds of
> years. (Set theory - Georg Cantor 1874, Predicate Logic from
> Aristotle 322BC to Frege, Peno, Godel and Turing & Church (1936) who
> prove that it is not "decidable").

I assume (and I can stand corrected) that this is set theory, and while relational theory springs from it, it's a stretch to imply that relational db theory was somehow even postulated in 1874 or before. But as I say, the theory may be provenaced there.

> 2) All computer software has bugs. Lots of them! When I start a
> project that will have some kind of DBMS, IMO the only choice is to
> start from "perfection" (no bugs). As far as I am aware, the
> relational model has no bugs and thus serves as the foundation for a
> "perfect" logical/business model. To start from anything else is to
> increase the number of bugs. Of course the actual implementation of
> the model may not be possible with current products and can/will
> cause bugs, but they should be fairly easy to spot.

Ah, this is where we can diasagree. I think the fundamental assumption here has a profound misunderstanding of how application software is developed (now maybe you can take issue with the 'how'...but that's another story.) Application software is a *lot simpler* than you think. Business rules have little to do with set theory and, in fact, a database. So when you say you 'start from "perfection"', to me that's so vague it's a moot point. I might start from perfection with the most perfect paints and brushes when I paint my living room, but if I'm a poor painter (practitioner) it wouldn't matter at all. On the other hand, a master craftsman can work with his 10year old battered brush and leftover paint and do better.

The point is, the number of bugs *may* be decreased by the purity of the underlying structure (of course, if you're saying that the alternative to the perfect db is one that actually *introduces* bugs, you do have a point, albeit a trivial (mathematically speaking) one,) but if, for instance, you use mv/pick you will not automatically be increasing your chances of bugginess. Integrity constraints, (etc. etc. ad naseum) can be enforced in both just as well or just as badly. There is no data structure that cannot be handled as well by pick or relational. There are significant pluses on either side and perhaps, significant minuses.

It's a matter of style-if you are more mathematically trained, relational will naturally appeal to you. Most of us in the mv/pick world, who are from various disciplines, mv/pick is more appealing because it is simpler, has a much lower learning curve and is more flexible. We do *not* think in terms of what the db 'models', it just is a data-handling mechanism that fits well with our abilities (and, perhaps, prejudices.)

To the user the choice...

Chandru Murthi Received on Wed Nov 05 2003 - 15:34:13 CET