Re: Pizza Example

In message <A3Ygc.78473$I%5.5263418_at_phobos.telenet-ops.be>, Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be> writes
>Anthony W. Youngman wrote:
>> In message <9Jugc.75998$vO4.5098632_at_phobos.telenet-ops.be>, Jan
>>Hidders <jan.hidders_at_REMOVETHIS.pandora.be> writes
>>>
>>> Sure. Retrieving records with an index is also very fast with DBM
>>>files. But what happens if you have a query with a couple of joins, a
>>>little aggregation and some subqueries?
>> Apply a little statistics. How likely is that going to occur with an
>>RDBMS, as opposed to a Pick DB. If the stats say it's unlikely to
>>happen, then why worry about it?
>
>In my experience, and of many others I've spoken to, the stats say that
>for certain applications and environments this is true, and for certain
>applications it is not. It is also my experience that in many cases it
>is understimated how difficult ultimately the queries will become.

As I understand it (I may well be wrong), most queries in a relational database are complicated/difficult because of joins. Viewed from a Pick mindset, the typical reaction is "what do you want a join for?". Pick doesn't have joins in the relational sense because it just doesn't make sense in the Pick world-view.

A bit like the Feynman story about calculus - Dick was taught an unusual technique and all his colleagues thought he was calculus genius. But as he said, they gave him all the problems they thought difficult, and with his different toolset he solved them easily. But if they'd given him the problems they thought easy, he would have been stumped.
>
>Take for example the Wikipedia database. (I mention it because it is
>open source and you can inspect the application yourself.) You would
>expect that the bulk of the queries are simple retrieves of
>encyclopedia pages and that this should be the most optimized
>operation. They discovered quite quickly that (1) the queries were
>actually more complicated than that and (2) if the really difficult
>queries were not optimized then the performance of the whole system
>went down the drain. Do you think that Pick would be suitable for such
>an application? They are now using MySQL.

In Pick, a simple retrieve would not be optimised. The unoptimised case is 100% efficient (give or take bugger all).

As for the difficult queries, with its different toolkit, would Pick think them difficult? If you could give me an example of a "difficult" query, I would be able to comment. Being a text-based system, Pick *ought* to be a good match.

I got the source of wikipedia on a cover disk this month :-) so I may well take a look at it. Only snag is, "I don't do Perl", which is I believe the language it's written in. But I ought to look at stuff like that :-)
>
>> That's what I meant about Pick queries being impossible to optimise -
>>the statistics say there's no room for improvement, or that any gains
>>by optimising the unusual case will be lost by hindering the typical
>>case.
>
>I know that's what you meant, and I still agree with that statement. :-)
>

:-)

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999