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.
See Also:
DynamicRelational EntityAttributeValue