gistfile1.txt

## Trait tables

An alternative idea I've been playing with recently takes inspiration
from game design, where ECS (entity component system) libraries are
the norm.

Objects normally can be thought of as a set of named fields. In an
ECS, an entity is just an id and it can have any number of
components. A component is the set of named fields traditionally like
an object, except we can have multiple of them.

ECS systems allow preserving the benefits of static typing while
allowing code to only care about the components it cares about. By
carving at the component level, we are able to build on some details
without being fully coupled to the implementation details.

Pointers allow us to point to records in a number of tables in the
database. By using ECS component-style tables (not themselves
pointable), code which cares about certain components may join to
those tables. Thus even though a pointer may point to conceptually
many tables, common components may be queried by code without having
to encode the knowledge of what the types are in the query. It's a bit
like graphql interfaces ("data interfaces") for the database.

When inserting a pointable type, it is up to the user's code to insert
the components they care about. When updating one, perhaps the
relevant components must be updated. When deleting one, you will have
to cascade deletes.