Our first implementation of qddb, which only allowed Boolean combinations of single-key queries, contained about 1000 lines of C code and was programmed by one person over the course of about a month. The name qddb stands for ``quick and dirty'', because our original intent was to provide a simple database package that would not require much effort to construct but would be useful to a wide community. Since then, we have expanded, enhanced, and (hopefully) improved qddb. Qddb now contains over 10,000 lines of C code, much of it devoted to QSQL. The QSQL interpreter is almost complete, and we hope to add embedded QSQL in the future. At present, there are few users, but the suite of programs has not been publicized, nor has various helpful software been written to assist the user.
Qddb meets its goals of portability and speed. We access relations from hosts of five different hardware architectures (Sequent symmetry, Sun 3, Sun 4, Vax, and DecStation) with identical code across the network file system (NFS) on different versions of BSD Unix. The same code also runs on various System V machines (AT&T 386, 3B1, 3B2).
Qddb is relatively fast. It takes an average of 5 minutes on a 16 MHz 80386 machine to stabilize a relation of length 3,138,793 characters (24,481 keys). Single-key queries take only 35-300 milliseconds to return a TupleList with 0-30 tuples on a stable relation using HashTable, not RandomHashTable. Reading and parsing a 20,000 entry sparse HashTable (mostly full) consumes less than 6 seconds. Reading and parsing a single hash table entry takes about 10-20 milliseconds on the average (used for reading the hash table on demand, possibly caching entries). Individual tuples can be read in 0.6-40 milliseconds, depending upon whether the kernel has cached the relevant portion of the Stable file and on the location of the tuple in the file. The most time-consuming single-key query that we can produce completes in under 800 milliseconds of real time (returning 30 tuples). TupleList intersection using two or more keys consumes well under 800 milliseconds, since the number of tuples in the solution set is decreased by intersection. The time for TupleList union is slightly less than linear in the number of keys.
We don't have many utilities yet. The following are fairly straightforward tools that would be worthwhile.