Re: Dreaming About Redesigning SQL

In article <bmpoap$oc47b$1(at)ID-125932(dot)news(dot)uni-berlin(dot)de>, Christopher
Browne <cbbrowne(at)acm(dot)org> writes
>>> How do you know it works? Without the theory and model, you
>>>really do not.
>>>
>> And don't other databases have both theory and model?
>>
>> It's just that all the academics have been brainwashed into thinking
>> this is true only for relational, so that's what they teach to
>> everyone else, and the end result is that all research is ploughed
>> into a model that may be (I didn't say "is") bankrupt. Just like the
>> academics were brainwashed into thinking that microkernels were the
>> be-all and end-all - until Linus showed them by practical example
>> that they were all idiots :-)
>
>In mathematics as well as in the analysis of computer algorithms, it
>is typical for someone who is trying to explain something new to try
>to do so in terms that allow the gentle reader to do as direct a
>comparison as possible between the things with which they are familiar
>(e.g. - in this case, relational database theory) and the things with
>which they are perhaps NOT familiar (e.g. - in this case, MV
>databases).
>
>Nobody seems to have been prepared to explain the MV model in adequate
>theoretical terms as to allow the gentle readers to compare the theory
>behind it with the other theories out there.
>
>I'm afraid that does not reflect very well on either those lauding MV
>or those trashing it.

I think one MAJOR problem is that most (if not all) MV practitioners are
not formally qualified in computing ... for example by education I'm a
chemist. And I'm doing postgrad in medical science ...

The trouble is - we MV'ers tend to take an engineering approach - we use
it because we know it works. To quote you from another post ...

>When people _don't_ do that "thinking differently," we are certain to
>see hideous performance, and that is neither a SQL issue nor a
>"relational" issue. The point is that if they are accessing a big
>pile of data, they have to think carefully [jumping to that "different
>way of thinking"] irrespective of what specific language(s),
>libraries, or other tools they are using.

Well, as far as we MV'ers are concerned, performance IS a problem with
the relational approach. The attitude (as far as I can tell) with
relational is to hide the actual DB implementation from the programmers.
So it is a design "flaw" that it is extremely easy for a programmer to
do something stupid. And you need a DBA to try and protect the database
from the programmers!

As soon as a requirement for a database specifies extraction of the
maximum power from the box, it OUGHT to rule out all the current
relational databases. MV flattens it for it for performance. As an MV
programmer, I *KNOW* that I can find any thing I'm looking for (or find
out it doesn't exist) with just ONE disk seek. A relational programmer
has to ask the db "does this exist" and hope the db is optimised to be
able to return the result quickly. To quote the Pick FAQ "SQL optimises
the easy task of finding stuff in memory. Pick optimises the hard task
of getting it into memory in the first place".

"Relational" is all about theory and proving things mathematically
correct. "MV" is all about engineering and getting the result. And if
that means pinching all the best ideas we can find from relational, then
we're engineers - of course we'll do it :-)

"Think different". Think Engineering, not Maths. And for $DEITY's sake
stop going on about science. Unless you can use set theory to predict
the future, relational has nothing to do with science ...

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