[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Updated Constrained OQL proposal
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.
Powered by eList eXpress LLC