This really depends on many things. How often are the individual tables
accessed and is the access spread evenly across them ? Also, what will
there be a lot more reading than writing or will it be a close ratio ?
We recently used sqlite in a multi-user environment using only a single
database and ran into some issues. The problem occurred because the
reads and writes were conflicting and we were getting a lot of "busy"
statuses. We resolved the problem by re-compiling and setting the read
lock attempts to blocking instead of non-blocking. It worked fine, but
obviously the more reads/writes going on, the slower things got.
Looking back, I probably would have split the databases up into 1 per
table because of the nature of our program. Either way will work, but
having a lot of reads and writes hammering on the same database files
requires higher timeout settings or blocking reads. I'd like to know
which solution you choose and how it works.
-Original Message-
From: Chris Ulliott [mailto:[EMAIL PROTECTED]
Sent: Friday, June 25, 2004 8:28 AM
To: [EMAIL PROTECTED]
Subject: [sqlite] Multi-User design
Hi All,
When using SQLite3 in a multi user environment is it better to have a
single table per database file or is it better to have just one file
which contains all tables in the database?
I am worried about the file locking, I do not want users to have to wait
for a table to become accessible just because another user is updating a
different table within the database.
What is the cost of performance if I put the tables into separate
database files?
Kind Regards,
Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
