Stanislav Sedov wrote: > On Fri, 11 May 2007 02:10:05 +0200 > Ivan Voras <[EMAIL PROTECTED]> mentioned: > >> - I think it's time to give up on using BDB+directory tree full of text >> files for storing the installed packages database, and I propose all of >> this be replaced by a single SQLite database. SQLite is public domain >> (can be slurped into base system), embeddable, stores all data in a >> single file, lightweight, fast, and can be used to do fancy things such >> as reporting. > > What is the reason to use SQL-based database? You'll perform direct > queries to database? The packaging system is for ordinal users, not sql > geeks, so they should not have to use sql for managing packages. So a
It's not SQL I'm interested in, it's the "additional" features:
- performance
- transaction safety ("commit all changes or none")
- constraints (like "unique" keys - sqlite unfortunately doesn't support
foreign keys)
- concurrent access (allowing to run multiple portupgrades at the same time)
- easy interface to C programs
If a BDB variety or some other storage layer can achieve these things,
I'll likely support them.
I know "Sleepycat" BDB implementations boast "transaction processing",
but can they offer this across multiple stores / databases at the same
time (i.e. like one transaction includes updates to multiple tables)?
Efficient (performance-wise) storage would probably need to use more
than one store, at least to index data by different keys.
signature.asc
Description: OpenPGP digital signature
