Does this go easier in any other ORM/DBs that you might have used? Sounds like the semantics of the real-world stuff didn't quite match up to the DB semantics.
We rolled a simple repository pattern library that fit over the SQLAlchemy Table API (no ORM objects, only tables).
Actually writing the the tables was very freeing, no more separation and surprises in the translation between a single model and the multiple tables it can create.
For each new object, we wrote a SQLAlchemy Table object, a domain entity object, and optionally an adapter if you need to map field names between the two. The 300 lines of repo library code did the rest.
A little boilerplate, but no need for a ton of impenetrable, hyper-dynamic ORM code.
Alembic can autogenerate migrations from the SQLALchemy Table objects
Actually writing the the tables was very freeing, no more separation and surprises in the translation between a single model and the multiple tables it can create.
For each new object, we wrote a SQLAlchemy Table object, a domain entity object, and optionally an adapter if you need to map field names between the two. The 300 lines of repo library code did the rest.
A little boilerplate, but no need for a ton of impenetrable, hyper-dynamic ORM code.
Alembic can autogenerate migrations from the SQLALchemy Table objects