- From: Keean Schupke <keean@fry-it.com>
- Date: Tue, 26 Oct 2010 14:50:16 +0100
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, public-webapps@w3.org
- Message-ID: <AANLkTin9H8QDYF1qq0Cy7a6fzAaBXcEqPX2hnpVDzYfG@mail.gmail.com>
> > >> I disagree, and I will argue the point. I don't see an argument for >> including optimisation strategies in a standard here. All DB engines make a >> good job of optimising most queries. I have written SQL for Oracle, >> Microsoft SQL Server, PostgreSQL, MySQL, and SQLite, and this has never been >> a problem. More likely bad performance is due to a bad schema and a bad >> design. >> > > This directly contradicts my personal experience and what I've heard when > talking to DBAs. If you read any book on optimizing SQL, you'll find that > the majority of optimizations for one engine will actually slow things down > in another. And this is sometimes true even between different versions of > the same database. (All of this is especially true of MySQL and SQLite.) > And this directly contradicts with my personal experience... and I have used SQLite extensively on the mobile platforms, and we just design the schema's and write the queries. For example take the FarmDB query from my earlier email: UPDATE Animal SET Animal.location=42 WHERE Animal.animalid IN SELECT Contaminated.animal FROM Contaminated,Animal WHERE Animal.type='cow' AND Contaminated.type='BSE' AND Animal.animalid=Contaminated.animal; This will run fine on all those databases with no changes or optimisations. That is what the query optimiser is for. You just write the query in the obvious way, and let the DB take the strain of optimising it. Even the worst performing of those databases is going to do a better job of optimising this query than _anything_ you or I could come up with, without investing many man-years of research and development. Do you think we can outperform either MySQL or SQLite with JavaScript code running in a web-browser? Even the slowest most un-optimised query will be better that that. To me this seems an idealist and impractical argument. We don't want a fast solution (faster than coding in JavaScript) because one implementation may be faster than the other? Cheers, Keean.
Received on Tuesday, 26 October 2010 13:50:44 UTC