*** 28,33 **** --- 28,36 ---- machines. (To be fair to db.*, it appears to be designed for use on embedded hardware where cross-platform is never a concern.) + Db.* uses a fixed record size (defined at compile time) for all records + in a single table. SQLite uses a variable-length records everywhere. + No direct comparision of the database sizes is available. However, based on the file formats one would expect a db.* database to use less disk space when all records are nearly the same size (contain strings with the same *************** *** 65,70 **** --- 68,90 ---- approaching 250KB. Both db.* and SQLite have a runtime database cache which is adjustable in size. + *Concurrency* + + Both db.* and SQLite appear to lock the entire database when making + changes to the database. Db.* uses a lock manager which runs as a separate + process. It might be possible to modify the lock manager to support + table-level locking in db.*. + + *Host Language Support* + + Db.* appears to be supported for C/C++ programs only. One could, + of course, create db.* bindings for popular scripting languages + or for java, + but the bindings themselves would need to be recompiled whenever + the database schema changed so this seem impractical. + + SQLite is written in C but supports bindings to dozens of different + programming languages. *License*
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|