From: Phillip Gawlowski <pg@...>
Date: 2010-01-15T11:07:20+09:00
Subject: Re: Recommended Reading (also:  Arrays/Hashes)

On 15.01.2010 02:55, Marnen Laibow-Koser wrote:
> Zach Bartels wrote:

>> So regarding DB issues with concurrency I
>> think SQLite will fit the bill nicely.
>
> On what basis do you think this?  Have you got a reason to think this,
> or is it just handwaving?

"SQLite usually will work great as the database engine for low to medium 
traffic websites (which is to say, 99.9% of all websites). The amount of 
web traffic that SQLite can handle depends, of course, on how heavily 
the website uses its database. Generally speaking, any site that gets 
fewer than 100K hits/day should work fine with SQLite. The 100K hits/day 
figure is a conservative estimate, not a hard upper bound. SQLite has 
been demonstrated to work with 10 times that amount of traffic." 
<http://www.sqlite.org/whentouse.html>

So, yeah, obviously SQLite is not able to handle multiple connections.

> Once you have 2 users -- or 1 user doing multiple simultaneous things --
> you have potential concurrency issues.  SQLite is not a suitable
> database in that case.  Fortunately, there are enough decent database
> abstraction layers for Ruby (ActiveRecord, Sequel, DataMapper...) that
> if you use one (and you probably should), switching DBs later on will
> not be a huge problem.  Just be aware that you're likely to hit a wall
> with SQLite fairly soon.

http://www.sqlite.org/lang.html

BEGIN TRANSACTION, END TRANSACTION, and COMMIT TRANSACTION are SQL 
features that SQLite supports. ACIDity is pretty much guaranteed when 
transactions are used.

--
Phillip Gawlowski