Re: Dreaming About Redesigning SQL

In article <mhMlb.2417$9E1.18525@attbi_s52>, Marshall Spight
<mspight@dnai.com> writes
>"Bob Badour" <bbadour@golden.net> wrote in message news:W46dnf4tbfF1DwiiU-
>KYgw@golden.net...
>>
>> All physical structures will bias performance for some operations and
>> against others.
>
>This strikes me as a succinct statement of the value of
>data independence. One has the option (but not the
>requirement) to adjust the physical structures the DBMS
>uses while keeping the logical model (and therefor all
>application code and queries, etc.) unchanged.
>
>Unless one has data independence, one does not have
>this option; one will be locked into a particular
>performance model. This is why I found the MV
>guy's obvious pleasure at being able to precisely
>describe the performance model for his DB as odd:
>I thought it a deficit to be able to say what it was;
>he thought it an asset.
>
When you park your car, do you put the chassis on the drive, the engine
in the garage, and the wheels in the front garden?

You may find my approach of keeping data together strange, I just find
it extremely weird that you think it is an IMPROVEMENT to disassemble
what is in the real world a single thing. I'm sure you would not be
happy if I tried to disassemble YOU and store your head in one place,
your legs and arms in another, etc etc.

Can I refer you to something called "emergent complexity"? A scientific
theory of how the whole can be greater than the sum of its parts?

Harking to something else, I can't remember who said "the tuple is the
fundamental unit of data". Apart from the fact that such a statement is
not worth arguing with, I would compare that to the quark in physics. A
strange beast that is known to exist, but can never be found in reality.
And as a chemist, it is totally and utterly irrelevant to me. It pays to
know it's there just in case in some strange circumstance it should be
useful, but for the most part I can ignore it as just not part of my
reality.


Oh - and do you know why I was so pleased to describe the performance
model for my db? For the same reason as I mentioned Huffman compression.
It's impossible to prove that that Huffman is the most efficient
algorithm, and indeed I pointed out that it isn't. It is, however,
possible to prove that it is mathematically impossible for a more
efficient algorithm to exist.

I'm TOTALLY happy to be locked into a performance model, if I can PROVE
that there are no other models that are more efficient. My ability with
stats isn't good enough, but the figure bandied about is that there is
room for about 5% improvement before we hit that mathematical limit. SQL
has a HELL of a long way to go to catch up :-)

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