On Mar 29, 2010, at 1:56 PM, Alexey Pechnikov wrote: > Hello! > > On Monday 29 March 2010 20:22:36 D. Richard Hipp wrote: >> SQLite version 1 used gdbm for storage. There were many problems >> with >> that approach: (1) gdbm is a hash-based system so it could not do >> range queries (2) gdbm is GPL, (3) Each table and index is in a >> separate file so your "database" was a directory full of files >> instead >> of a single file, (4) there is no support for transactions, (5) gdbm >> is highly vulnerable to corruption if a power loss occurs while it is >> being updated. > > May be the Tokyo Cabinet DBMS is more better? BerkeleyDB is required > administration and it's strange solution in many embedded devices and > for some desktops and servers too.
(1) Tokyo cabinet did not exist in 2001 when I was looking for an alternative to gdbm. (2) When you configure Tokyo cabinet so that it is robust against power loss (so that it doesn't corrupt the database file during a power loss) it is about 10x slower than SQLite. (3) Tokyo cabinet has less concurrency than SQLite. (4) Tokyo cabinet is not able to put an entire SQL database into a single file. It would require a directory full of files, just as gdbm did. (5) Tokyo cabinet does not support transactions across files, so it cannot be used in an SQL engine that is transaction (since at the SQL level you must have transactions that span multiple tables.) I can come up with additional reasons why replacing the existing SQLite backend with TC is not a good idea, but perhaps the above will suffice. D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
