roman.kyrylych at gmail.com
Thu Oct 26 16:24:08 EDT 2006
2006/10/26, Aaron Griffin <aaronmgriffin at 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 (Роман Кирилич)
More information about the pacman-dev