Proximity Database

A database with two tables: A "record" table and a "link" table, each with a very few attributes. All intelligence coming out of the database is the product of joins between those two tables. For more information, and a more accurate description, see ProximitySoftware.

Even better: a database with a "relation" table for storing binary relations of various classes, a one-column table of objects, and a set of tables for holding "fields" of various data types. Each field gets a field class. Implementing collections in such a monster is a matter of defining more than one instance of a field for a particular object. So, rather than two tables, you have one table for a particular data type in the underlying database system. A bignum_fields and long_int_fields table, for example, and a text_blob_fields table.

Advantages:

not so hard to coerce these things into NormalForm.
the data structure is way more flexible, and can be modified and extended very cheaply
space savings
semantically, relation fields are different from other big_int entries. Deriving structure becomes a bit easier.

Disadvantages:

essentially you're implementing a database in a database.
concurrency becomes more of an issue than with table-level locking.
you're marshalling objects into a referential system.
it can get silly very quickly.