I would strongly consider using normal sqlite to store your key values pairs.
do you have a performance spec that you need to meet that would not allow that? Also you could just try it out to see if it is "good enough". On Tue, Sep 9, 2008 at 2:59 PM, Lawrence Gold <[EMAIL PROTECTED]> wrote: > Hello, > > I work for a company which is seeking to replace its homegrown > database engine with a more robust, modern engine. I've looked at > BerkeleyDB, which would be ideal since all we really need are key/ > value pairs for our records and indexes, but its cost is rather > prohibitive. > > At this point I'm considering targeting SQLite's internal B-tree API > directly, realizing that I'm assuming some risk as the API isn't > guaranteed to remain stable between releases. Before I delve into > this, can anyone suggest a better approach to using SQLite in a lower- > level manner for storing key/value pairs? > > drh mentioned the SQLite Stored Statement Extension in a post last year: > > http://www.mail-archive.com/sqlite-users@sqlite.org/msg23591.html > > Does it in fact have an API that would lend itself well to key/value > pairs? > > Thanks! > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Jim Dodgen [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
