ORM relationship decorators are only trustworthy when they match the actual database constraints, indexes, and query behavior.
From my notebook
Where this came from
This is the order I use when a TypeORM relationship behaves differently from the entity definition. I check the actual constraint, migration history, generated SQL, and production data shape before changing decorators. That order has prevented several code-only fixes from hiding a schema problem.
My short checklist
TypeORM can make relationships feel simple, but the database is still the source of truth. A decorator can say one thing while the schema, migration history, or production data says another. When relationship behavior looks strange, I do not start by renaming decorators. I inspect the generated SQL and the actual database structure.
The first step is to verify foreign keys, nullability, indexes, and join columns in PostgreSQL. A relation that is optional in code but required in the database will fail at write time. A relation that is required in code but nullable in the database can create confusing runtime assumptions. Both are design problems, not just ORM problems.
Eager relations feel convenient until list endpoints become heavy. A small entity can pull a large graph into memory because one decorator says eager true. I prefer explicit relations for read paths and separate query methods for list, detail, and admin screens. Different screens usually need different shapes.
The important question is what SQL gets executed. Does the query join too much? Does it produce duplicates? Does pagination happen before or after relation loading? Does it rely on nullable columns in a way the UI does not expect? Looking at SQL removes a lot of guesswork.
Relationships should represent business rules. If a ticket must always belong to a customer, make that rule visible in the database, the entity, and the service. If a document can outlive the user who uploaded it, model that intentionally. The ORM should express the rule; it should not be the only place the rule exists.
The safest TypeORM work keeps code and database reality synchronized. Decorators, migrations, constraints, indexes, and query tests all need to tell the same story.