On 4/1/10 4:12 , "Neville Franks" <sql...@surfulater.com> wrote:
> 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. > > > Also from the "end user" perspective it is so much easier for them to > backup or copy a single file. > These two answers are void in the context of the Wiktor's point who said "For example mac application is a directory not a file and no one complains". The reason no one complains is that an app directory is seen by the user as a single entity (a "bundle"). S/he doesn't have the option to copy/backup parts of it. (except through geeky, explicit actions). Of course, the other operating systems don't care much about such details, nor about users in general, so your points are valid in general, just not in Wiktor's context. I think an interesting point can be made that splitting the database in several files (or forks, such as provided by HFS or NTFS) really means deferring parts of the DBMS's job to the file system. It could even be argued that using files in the first place is already deferring to the OS! So at one end of the spectrum the DBMS defers at little as possible to the OS, while at the other end of the spectrum, every table, or even maybe every row is in its own file. There are advantages to storing every row in its own file: the database becomes compatible by system-wide search facilities for example. This is why Apple went from a single-file mail database to a scheme where every mail is in its own file. Now you can use spotlight to search for emails. And to be clear, I agree that a single-file data format was the right choice for SQLite :-) Jean-Denis _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
