On Sun, Jan 2, 2011 at 1:48 AM, Edwin Eyan Moragas <e...@yndy.org> wrote: > Thanks to Marco, Marc and Jim for the responses. > > gives me a warm, fuzzy feeling to go on ahead and continue using SQLite.
> having looked into its innards, i'm trying to see how much time it > would take me to remove the SQL shiz from it. maybe in a year's time. little need for that. a key/value table and a prepared statement with bound parameters is basically a direct interface. the C interface to a btree isn't going to look much different. the overhead is about 0. i've built what amounted to a file system in sqlite without taxing it too heavily. several gigabytes of data. the only problem i've ever had with sqlite was shortly after the query optimizer was added, it rather spectacularly unoptimized a hand tuned query. this only affects fairly complicated sql queries, and is corrected easily enough by rewriting the query using some tricks. i will also add that you should never put a sqlite database on nfs if you can help it. this is not sqlite's fault, but file locking on nfs simply doesn't work. bad things will happen, sometimes even if you're not sharing the database.
