RE: Updated Constrained OQL proposal

[David RR Webber <Gnosis_@compuserve.com>]

Message text written by Matthew MacKenzie
>> The changes are:
>
> -Much more examples on the types of queries IMHO need to be supported
> -Now uses attribute names rather than accessor method names wherever
> possible
> -Added section on mapping OQL to SQL
>
> I look forward to your comments.
>
<<<<<<<<<<<<<<<<<<<<<<<<<<

Farrukh,

Unwhitingly or otherwise your further examples use the 

SELECT DISTINCT ..... method.

I could not have asked for a better example for why the
OQL approach is fatally flawed.

SELECT DISTINCT is a server killer.  I know from first-hand
experience.   I did some consulting for a major USGov
web site (in the top 15 ) - they were set to spend $250,000+
on new hardware as queries had degraded to run in 
15+ minutes (yes!).  They had 3 fulltime DBA's and a army
of other consultants that had focused on the problem
for one year.    It took me 2 days to discover they had
47 procedures using DISTINCT where it was completely
not needed.  I replaced these with the correct cascading
SELECT ( ) equivalents and response times dropped to
 7 seconds across the board.

I of course was the most unpopular person in the 
building as management promptly cancelled the
new hardware purchase.

What this shows is that relying on a specific query
syntax is fraught to say the least.   I would not allow
anyone to run a SELECT DISTINCT against my
SQL backend across an open channel.

I like Matt's suggestion of an API based on 
methods as the best option.

Now back to typing that WP!

Thanks, DW.