Thursday, April 1, 2010, 12:16:13 PM, you wrote: JJD> On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski JJD> <bardzotajneko...@interia.pl> wrote: >>> There were many problems with >>> that approach: >> ... >>> (3) Each table and index is in a >>> separate file so your "database" was a directory full of files instead >>> of a single file >> >> This one is not a problem. Actually I don't see how 1 file is better >> than 1 directory. For example mac application is a directory not a >> file and no one complains. And with several files database would be >> faster (for example dropping a table is instant or fragmentation is >> handled by OS without need for vacuuming whole database). Also with >> current SQLite implementation only tables would be locked by a >> transation not a whole database (a few years ago there were even >> document on SQLite website listing splittnig database to several >> files as one way to implement table level locks in SQLite). >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >>
JJD> Two reasons I prefer the single file approach: JJD> 1. Simpler copy, tables and indexes don't get lost or mismatched. JJD> 2. fewer handles to open a database. Lower overhead. JJD> This still is a small footprint, high-performance, low overhead SQL JJD> implementation. It does what it needs to do and no more. Also from the "end user" perspective it is so much easier for them to backup or copy a single file. --- Best regards, Neville Franks, http://www.surfulater.com http://blog.surfulater.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
