Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:moderators: Parent is not a troll (Score 1) 401

I know of plenty of projects using SQLITE. For megabyte to tens of megabyte size database, SQLITE is GREAT. For hundreds of megabytes, it can still be good, but needs careful design and tuning. For 100s of megabytes, use a client/server DB

We use it to back our web based products. The concurrency isn't great but can handle dozens of users easily. We have DBs ranging to the gigabyte size. To date, in the past 4 years, there have been virtually no serious issues with SQLITE.
Pros:

quality code, excellent free and paid support
public domain code
excellent SQL 92 compliancy, with the exception of GRANT/REVOKE, which aren't relevant on this kind of DB
compiles on tons of platforms from embedded to Windows/Mac/Linux.
Fast, especially for SELECTs
ACID
UTF8/UTF16 compatible
Full Text search module available (caveat: I haven't tried it and don't know how good it is)
Well documented
Thread safe

Here are the caveats:

- As noted, it's not client/server. So it's concurrency is limited. Multi users apps should carefully consider their usage of SQLITE. You can work around this up to a point of course, but eventually you'll hit contention.
- For 100MB+ databases, consider client/server also.
- SQLITE can only use one index (single or compound) in the WHERE column.
- INSERTS are slow unless you batch them. This is because you are opening, closing, and flushing each time. So if you do one INSERT at a time, you'll whine about the speed. The time to insert say 10 things one at a time, is in my experience about the time to insert 1000 rows when wrapped in a transaction
- Both pro and con: a db is a single file. That makes it easy to deal with, but can be problematic in some cases, especially larger DBs

Slashdot Top Deals

Theory is gray, but the golden tree of life is green. -- Goethe

Working...