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