chris wrote: > > I suppose this comes down to how the db is accessed. If ... the db is a > memory-mapped file that is only partially read as needed based on the index, > then combining everything into one db/multiple tables (like a relational db > model) would be the best method. >
It is more complicated than that, actually.
SQLite does not memory-map (since SQLite supports database files larger than the address space of most processors) but it does read only those portions of the database file that it actually needs. So even if your database is gigabytes in size, only a few kilobytes would be read from disk on a typical query.
But there are still advantages to keeping many small databases instead of a single big database.
1. Everytime you call sqlite_open(), SQLite must read and parse
the entire database schema. This is surprisingly quick, but
you still might want to keep your schema small if you are
calling sqlite_open() a lot. 2. SQLite uses course-grained locking. While most client-server
database engines lock a table or row of data at a time, SQLite
locks the entire database. So if concurrency is an issue for
you, it is better to break the data up into separate files
so that you can have more (and finer grained) locks.Note that you do not lose relational capabilities by keeping data in separate files with SQLite. SQLite has some non-standard extensions (ATTACH and DETACH) that allow it to do joins on tables contained in separate databases.
-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
