On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski <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 >
Two reasons I prefer the single file approach: 1. Simpler copy, tables and indexes don't get lost or mismatched. 2. fewer handles to open a database. Lower overhead. This still is a small footprint, high-performance, low overhead SQL implementation. It does what it needs to do and no more. -- Jim "Jed" Dodgen j...@dodgen.us _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
