Re: Dreaming About Redesigning SQL

In article <bn31nq$aiq$1_at_gazette.almaden.ibm.com>, Paul Vernon <paul.vernon_at_ukk.ibmm.comm> writes
>> Note I didn't say relational is *incorrect* - the ideas of
>> "mathematically correct" and "scientifically provable" are orthogonal,
>> and have nothing to say about each other.
>
>Fair enough. Maths just has to be self consistent (given some axioms),
>Science has to be 'useful', in that it predicts what is possible, what can
>happen.
>
>You'd agree that the relational model is self consistent - or at least
>you've no reason to doubt that? OK. Is it useful, or more importantly is it
>*more* useful than any other self consistent model that has been proposed?

Yup. I'd agree. In case you hadn't noticed, I have said that I think in a relational manner - and would recommend it as essential for any database programmer ... I just feel that as a *mathematical* *theory*, any attempt to enforce it is likely to be counter-productive, because the real world is not a theory ...
>
>Well, our answer is that is it *more* useful because it is necessacary and
>sufficient for logically representing data. There is no data that is not
>representable as sets of like tuples in a set of relations. Any other known
>representation, such as lists, arrays, trees, networks etc adds no extra
>data representation capabilities. Moreover any other representaion adds
>complexity (aka stuff) but not any extra power.

And I don't see how MV is incompatible with your belief ...
>
>What relational theory predicts is that a system that needs data persistence
>will be more complex if built on a non-relational foundataion than on a
>relational one - everything else being equal.

Dunno about that :-)
>
>I'll admit to not knowing if the above has been formally proved, but, well
>I'm tempted to say it's obvous ;-)

Everything else being equal - that's a very big assumption. "Obvious", based on potentially false assumptions, could lead to disaster.
>
>Now, I might be generous and say that the above is predicated on the
>assumption of data independence - the idea that the physical layout to store
>the data be separated from the abstract representation that user use to
>view, create, query and modify that data. So if don't believe in this
>principle (which I suspect you don't) then I guess we will struggle to
>convince you of the essentiality of the relational model.

Yes - I most definitely DON'T believe in that. You notice I gave Lauri a formula to calculate how long a query would take. I don't think he succeeded in convincing me he could reciprocate in kind (I've still to study his answer), and proving that a query will complete in finite time is of no use if "finite time" equals "longer than I can wait".
>
>For myself, I do happen to think that physical data independence is not
>quite a perfectly achievable ideal. The ideal would be that all queries, no
>matter how complex, would take the same time to execute, or rather that
>execution time would be directly proportional to query complexity - which
>would be knowable at compile time. I don't know that such an ideal is
>possible, but I do know that we can get close, and that fall backs such as
>up front query time estimates produced by relational execution engines help
>bridge the gap. To give up, and expose physical matters (i.e. performance)
>via the logical model, is in no way warranted in the general case.
>
>A model that exposes users to the physical might have the benefit of giving
>users more direct knowledge of expected performance, but the cost in lack of
>generality is way to high (for all but the most specialised situations, or
>the most messed up market places).

Actually, I would contend that the MV model gives you exactly what you are looking for here - execution time IS proportional to complexity. We do expose the theoretical to the physical, and the "cost in lack of generality" is negligible. *IF* (and it's a big "if") an MV database is correctly designed, the main difference between MV and relational is that we map a physical "blob" to a physical entity. And the transform from an MV blob to a relational view is of negligible cost.
>
>Regards
>Paul Vernon
>Business Intelligence, IBM Global Services
>
You work for IBM - why don't you investigate IBM's own MV products, namely UniVerse and UniData (collectively known as U2). Maybe we'll convert you :-)

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let 
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett