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