On Fri, Dec 02, 2005 at 10:56:56PM +0000, David Cantrell wrote:
On Fri, Dec 02, 2005 at 05:28:46AM -0500, IvorW wrote:
Surely if you want to make it as easy as possible, SQLite would be a better option?
Sorry, SQLite won't scale. Concurrent access and locking is something that SQLite doesn't do, though it does have transactions and rollback.
Does it scale *enough* though? I can't imagine that the London guide (which I imagine is still the biggest) ever has more than ten concurrent users reading it and more than 2 or 3 writing it.
I ran a guide using SQLite at one point (Manchester, NH) and even my personal use (one person) would bump into weird SQLite errors.
Also, as I said, SQLite is probably *less* likely to be supported with the appropriate perl modules for DBI than MySQL is.
Given the problems with SQLite, I think that it would be better to just stick to MySQL for any major uses.
I'm already seeing some slowdowns on Boston in some pages, so I may be looking to add some caching to different aspects of the page - specifically, when loading ?action=index;format=map (which is still one of the more common page requests I see), which loads *everything* in the DB, it's slow. So, I think that if we're going to go for the whizbang nature here, loading all the data may be more likely, and SQLite is not going to be scaling "enough".
Skip the pain. MySQL isn't that big of a requirement. SQLite may be more painful. Let's not hurt OG by encouraging using a possibly non-scaling database product which users would then later have to move from to serve their users. The "Slo-penguides" joke has already been made even with the "real" databases :)
-- Chris