Re: Dreaming About Redesigning SQL

"andrewst" <member14183_at_dbforums.com> wrote in message news:3571843.1068213473_at_dbforums.com...
>
> Originally posted by Mike Preece
>
> > > > Why were RVAs intoduced (or accepted) into relational theory
> > in the
>
> > > > firs..., I mean, 10 years ago?
>
> > > If you really want to understand this,
>
> >
>
> > Not really, to be honest.

Honesty at last. The ignorance is willful.

> > From what I've read I'm pretty sure we've

You read?!? Well, I suppose that's trivially true if one ignores comprehension.

> > It's logical to store phone numbers against a person. It's also more
> > efficient.
>
> .. in Pick. It is not more efficient in an RDBMS. But anyway my point
> was that you are saying that the query by phone would also be "extremely
> efficient". But presumably not AS efficient as the query by name, since
> you say that is "more efficient".
>
>
>
> So, you have:
>
>
>
> Query By Efficiency
>
> Name X
>
> Phone Y
>
>
>
> where X > Y
>
>
>
> Whereas in relational we have:
>
>
>
> Query By Efficiency
>
> Name X
>
> Phone Y
>
>
>
> and we can choose whether X = Y, X > Y or X < Y according to decisions
> made at the PHYSICAL level, which do not require any change at the
> LOGICAL level, i.e. the SQL for a given query remains unchanged.
>
> You of course will contend that the Pick X is better than the RDBMS X,
> and I will disagree, but we can't really test that here can we?
> However, I will say that in Oracle (e.g.) it is perfectly possible that
> the query to list "Mike" and all his phone numbers can be achieved with
> 1 disk read, provided the data is clustered and fits into 1 block
> (typically 4K or 8K); or 0 disk reads if we read the same block earlier
> and it is still in the cache.
>
> > > > Let's look at the evidence:
> > > > We agree that the person is more relevant in the persons to
> > phones
> > > > relationship.
>
> > > But we disagree over whether that is necessarily relevant to
> > logical
> > > database design.
>
> > I thought we agreed that when we were concentrating only on logical
> > design.

If that is so, why does he constantly mention efficiency? He is too ignorant and too stupid to know the difference between logic and physics.

> It just so happens that Pick has no concept of logical/physical
> distinction. That is Pick's handicap, not relational's. Sorry if you
> have a hard time understanding that. You have NO CHOICE over logical
> design: it HAS to correspond to the physical design you select for
> performance reasons; we have choice: our logical design is optimised
> for querying, our physical design is optimised for performance.
> Forget RVAs.
>
>
> > Maybe it's time for a new thread. This one has gone OT.
>
> Agreed, this should come to a close. If you still don't get what I've
> been saying, then you never will. This is probably due as much to my
> shortcomings as a teacher of the relational model as to your failure to
> understand what I have said.

Nah! Even if you had no shortcomings at all, Mike would still fail to learn anything. He simply lacks the ability to learn. The only interesting question is: Is Mike's cognitive void innate or was it acquired through Pick use?

> > from disk (irrespective of the size of the Phones file). Oh I get it -
>
> > Bob's 8-fold improvement jiggery pokery trick? Ha. Haha. Ha. Hmmm... I
>
> > guess my sense of humour must be different to his. Seriously though -
>
> > what is the equivalent SQL statement to get the same information?

There was no jiggery pokery. You simply lack the ability to conceive reality. If your fantasies amuse you, I am happy for you.

> And no, we can't beat your single read of 2k from disk

Sure we can. You lack imagination. I suggest your pedagogic approach is counter-productive.

> > Would the statement be identical whether the data is coming from the
> > PersonsPhones table or from RVAs in the Persons file?
>
> No, because those are 2 different LOGICAL designs. But the statement
> would be identical regardless of any physical optimisations we might
> make such as:
>
> 1) physically cluster the phone data with the person (like your Persons
> file with the phone MV attribute)
>
> 2) physically cluster the person data with the phone
>
> 3) store the phone data and person data independently
Received on Fri Nov 07 2003 - 16:19:32 CET