On Thu, May 06, 2004 at 09:54:24AM -0400, D. Richard Hipp wrote: > Concurrency is not nearly as much an issue in reality > as it is in many peoples imagination. Concurrency > probably is not an issue for a website. If concurrency > really is an issue, you need a client/server database.
While that might be true [I take no position on whether it is or not], to some real extent it may also be irrelevent. Here's my theory: People often don't know ahead of time, and aren't able to reasonably predict, just how much concurrency they will need. Also, their concurrency needs may change over time, again in ways that are hard for them to predict. Therefore, picking a tool which they KNOW has serious concurrency limitations introduces a significant risk, the risk that they may have to drastically overhaul their underlying tools and architecture at some unknown point in the future, due to hitting concurrency problems and thus suddenly discovering that they're now using the wrong tool for the job. Since SQLite's concurrency support is very limited, potential users are forced to pre-maturely optimize: Either believe you will need high concurrency, and go with PostgreSQL or Oracle, or believe you will need no or low concurrency, and go with SQLite. Premature optimization is a bad thing. There is a missing middle ground there: A medium-concurrency SQLite. If a future version of SQLite - let's call it "SQLiteMC" - were able to significantly increase concurrency, while at the same time preserving all or most of SQLite's historical advantages (simplicity, etc.), this would significantly expand the problem domain to which SQLite is applicable. That, in turn, would reduce the "wrong tool" risk of using SQLite, and both of those effects would tend to make SQLiteMC both more useful and more widely used than SQLite is now. That's my little mental model anyway. To me the direction of those effects seems just about certain, but what I don't know - and can't know, much less quantify - is the size of those effects - they could be anywhere from zero to large. And of course, that's assuming that SQLiteMC succeeds in its technical goals. And would SQLiteMC succeed in its technical goals? How hard would it be, and are there sufficient programmer resources available to make it happen? That I don't really know either, but together, Dr. Hipp plus a few other experts on this list could probably come up with a reasonably good idea... -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
