Re: In an RDBMS, what does "Data" mean?

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:ia4f9vJn0jzAFwWF_at_thewolery.demon.co.uk...
> In message <c0e3f26e.0406100132.6b88c3e5_at_posting.google.com>, Tony
> <andrewst_at_onetel.net.uk> writes
> >"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> >news:<0UZ6uTSqd7xAFwl0_at_thewolery.demon.co.uk>...
> >> Relational needs an optimiser - Pick gets it for free ... and the stats
> >> say that on average it pays off handsomely :-)
> >
> >Pick doesn't have a "free" optimizer: it just doesn't have one. So
> >either there is only one access path, and too bad if it isn't optimal,
> >or you the designer/programmer are playing the part of the optimizer
> >yourselves (and I don't suppose your time comes free).
>
> So our time isn't free ... but optimisation is inherent in the design.
> We don't even think about it - it just happens ...

Having spent some years trying to teach PICK folks to use SQL as a query language (don't worry, I saw the light) I can definitely vouch for ths as a MAJOR difference between the MV query language and SQL. Users who had been accustomed to MV Query langauges couldn't believe they had to work so hard to get a good SQL query from the same data. Of course, there are better optimizers than what they had in the product at that time, but nothing holds a candle to the query language they were used to.

I'm hopeful that someone will write an implementation of GIRLS (mv query) that goes against XML data so others can benefit from the language. It needs some updating since it hasn't changed much in 40 years, but it sure beats XQuery for ease of use by a hardly-trained human.

Cheers! --dawn Received on Tue Jun 15 2004 - 03:25:29 CEST