> On 2006.07.02, Andrew Piskorski <[EMAIL PROTECTED]> wrote: > If all you're using MySQL (or any SQL-fronted data persistence > mechanism) for is key-value lookups, then something like BDB ought to > win because SQL parse time overhead is not zero. SQL is not "free" in > that regard.
Oracle caches parser and planner results ... the OpenACS db API allows for the caching of entire query results under control of application programmer. There's more than one way to skin a cat, in other words. > Of course, the *ONLY* compelling reason to push SQL into the DBMS using > stored procedures is the optimization around SQL parse time: parse it > once, store it inside the DBMS, to remove that cost at the per query > execution level. This makes sense when you have queries that are > short-lived and are executed rapidly, which can often be the case in > web-based applications. Oh, there are other reasons, as well. Abstraction. Taking advantage of the RDBMS's ability to avoid execution of the function at all under certain circumstances (PostgreSQL allows one to tell the optimizer that a function result is constant over the lifetime of a backend process, or during the lifetime of a single transaction, etc etc). > Again, the problem in the small (10 servers doing 40 q/s) is easy to > solve. But suppose you had to handle, say, 1MM q/s. Would you rather a > solution that required 2,500 servers, or 25,000? That factor of 10 gets > exponentially harder to support given physical requirements. When one builds systems at the very high end, one may very do what Google has done - write custom solutions that are much more efficient than *any* off-the-shelf solution. Then again, when working at the very high-end, one is likely to have the money to invest in such things. Most of us aren't so lucky. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
