Re: foundations of relational theory? - some references for the truly starving

> Costin Cozianu wrote:

> > Mike Preece wrote:

> > > Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message
> news:<bn3nbs$seug1$1_at_ID-152540.news.uni-berlin.de>...
> > > [snip]
> > >
> > >
> > >>You could compensate if you wanted by a careful thought out scientific
> > >>work to prove exactly what your model buys the user.

It *is* a damn shame no one has done this already - afaik. Any authors out there able to spot an opportunity?

> > >> Actually, the work
> > >>was kind of done for you, theorists have analyzed the model and reached
> > >>the logical conclusion that there's not much to it.
> > >
> > >
> > > References please? Don't bother pointing me to Date's inconclusive
> > > "research done on the web". I'm more interested in the complete
> > > analysis with the logical conclusions. I suspect (strongly) that it
> > > doesn't exist. I concede that there are, however, a vast number of
> > > theorists that *assume* incorrectly (and illogically) that there's not
> > > much to it. I'd ask each and every database theorist reading this
> > > thread to ask themselves "what is the basis in fact for this belief?".
> > >
> > >
> > The basis in facts are very simple: Nested Relations offer no extra
> > expressive power, and plenty of complications.

Let's just pause a moment.

You are talking about "Nested Relations" - with capitals no less. You could have said "Pick" or "MultiValued" - but you chose not to. I think we have to be careful about what's meant by that exactly.

Oracle has "Nested Tables"
(http://www.dba-oracle.com/art_9i_data_model.htm). They have *pointers* to the location of the nested rows. This is *not* Pick/MV.

In Pick the nested rows don't need pointers - they are in-situ. The item, or record, contains all of the related data - hence we get it all in a single read. No need to "dereference" anything. Not such a "plenty of complications".

Fans of Pick (like me) state time and again that Pick is simple. Don't take our word for it. Look at the real world. Look at the IT departments, their expenditure, the staff levels - and all the rest - and compare. It's simplicity is why there are a great many businesses out there running on Pick systems with far fewer resources than would be required to run comparable SQL-relational database systems. I doubt you'd believe how "lean and mean" many Pick systems run. Might be interesting to find out. There's another opportunity folks - this time for a survey as well as a publication. I promise I'll shut up forever if I'm wrong about what you'll find - if you look properly.

> > There is nothing to be had by adding nested relations to the relational
> > model.

Not if it's implemented the way Oracle have - I completely agree. It needs a more fundamental change to the *SQL-* relational model. Wayhey! That's kinda similar to the title of the thread! Important difference though don't you think - that *SQL-* bit?

> > Adding nested relations to it it's like adding an operator Y to
> > classical arithmetic a Y b = a + b - a * b, it is totally unnecessary.,

If my assumption is corrrect - and you are talking about "nested tables" in the Oracle sense - then I agree completely. As the article I provided a link to states: "However, it sometimes takes longer to dereference the OID to access the nested table entries as opposed to ordinary SQL tables join operations. ". No great surprise there then. Pick - as I've already said - doesn't need to dereference anything, the related data is in-situ.

> > >>Even more, the model
> > >>is already available one way or the other in existing SQL DBMSes,
> > >

Don't you think "one way or the other" is a little loose?
> > > Yes and no. Yes - the SQL "relational" vendors are slowly coming
> > > 'round - although the way they implement roughly equivalent capability
> > > is nowhere near as slick as traditional "Pick". No - because what
> > > they've come up with ("nested tables") is a "bodge job", very poorly
> > > implemented, and is therefore rarely used.
> > >
> > >
> > And may we know *exactly* why it is very poorly implemented in your
> > opinion ?

I refer the honourable gentleman the the answer I gave some moments ago.

> > >>but
> > >>typically I don't use it and most people don't use it, for very
> > >>practical reasons.
> > >
> > >
> > > Yes. Because "nested tables" is a very poorly done bolt-on.
> > >
> > >
> > Not at all. But because nested tables or however you want to call them
> > are pretty much useless.

Yes. Pick, on the other hand, is fundamentally different and far more useful.

> > >>You can't blame the "theorists"
> > >
> > >
> > > Sure I can - when they make incorrect assumptions, criticise what they
> > > don't understand, and are prepared to believe others that have done
> > > likewise.
> > >
> > Oh, yes, please. The grand conspiracy of database theorists.

Hmmm. Nope. Not a clue what you're on about. Sorry..

> > >>when you have very practical and serious
> > >>problems, like for example your clients investing in an obsoleted
> > >>technology with problematic future. And it is ridiculous for you guys to
> > >>whine that theorists disregard your model, actually they don't, it's
> > >>described in all theory books (now that I know it's actually about
> > >>nested relations), they just are not so crazy about its virtues.
> > >
> > >
> > > Again - references please?

> > Abiteboul, Hull & Vianu, they are very much neutral on the subject.

I promise I will follow these references up some time - if they really are regarding and describing the Pick model, even if they choose to call it something else (although I don't know why they would choose to call it something other than Pick or MultiValued - they should realise that they'll miss much of their target audience). Hmmm. I'm not feeling very confident... I'm afraid it's going to have nothing at all to do with Pick... What do you reckon folks?

> > > Describe what you know about "nested relations" and
> > > we'll see.
> > >
> > Your attitude is completely idiotic. Are you asking me to prove my
> > competence to you ?

No. See above. I wanted you to describe "nested relations" as you know them. As you haven't given me a description I've guessed that maybe you mean something similar to Oracle's "nested tables". Please corrrect me if I'm wrong - good sir.

> > Considering how much knowledge you've shown so far,
> > I'd say you're pretty much clueless.

Damn. Your opinion matters a great deal to me. Uh Hmm.

> > It is you who should give me a good reference -- not marketing idiocies
> > about how "joins are difficult to compute" --, that you consider
> > relevant for showing the difference. And we'll see.

Ummm. I think you have me confused with someone... else. Never mind. A lot of it going 'round don't you know?

> > > Regards,
> > > Mike.

> > Regards,
> > Costin

And regards again,
Mike. Received on Wed Oct 22 2003 - 13:47:49 CEST