2006/10/26, Aaron Griffin <aaronmgriffin@gmail.com>:
Personally, I think sqlite will be the best choice because of: 1) it's small 2) it's fast 3) it's embedable
Ok, sqlite is "fast and etc etc", right? So if I do [pacman -Ss foo], what does sqlite do? It opens the file (exactly as plaintext searching would), initializes some structures and things like that describing table data, then proceeds to sequentially search (FULL TABLE SCAN) through all rows. It is impossible, even in a good database, to index substrings. Yes, you can index entire strings, that's easy. The search operations check internal substrings, not whole strings. . . . . . . . . . . I don't get what you whant to say here. Using SQLite will not allow full text search to be faster or slower, but easier, because all needed functions are already there. You don't need to do complex indexing. Indexing by package name is enough. By terms "small, fast, embedable" I mean that it's better than MySQL or something else. And it's better than dbm-style databases when it comes to random writing and transactions. And yes, it is faster than filesystem backend, because there is a _simple_ way to use _in-memory_ databases! ;-)
4) it offers full power of SQL99 (with ACID transactions!!!)
Nope. Not at all. It doesn't even support SQL92 - a 14 year old standard. Oops, my bad, I confused SQL99 with SQL92. :-p Anyway, SQLite offers many functions almost for free. And anyway there should be a choice of files/gdbm/sqlite/whatever.
-- Roman Kyrylych (Роман Кирилич)