Database Engineering

Model persistent truth from invariants and access patterns, not from ORM convenience.

Workflow

Inspect the existing database engine, schema/migrations, repository/data-access conventions, and actual workload.
State the invariants and authority of the data before choosing tables/collections, keys, or abstractions.
Model identity, ownership, cardinality, lifecycle, nullability, uniqueness, and referential constraints explicitly.
Define transaction boundaries from atomic business invariants.
Derive indexes and query shapes from real access patterns and ordering/filter requirements.
Consider concurrency and isolation only to the depth required by the invariant; do not add locks or serialization without a concrete race.
Use engine-specific features only after the project engine is known. A specialist provider can help with syntax/tuning, not silently choose the engine.
If existing data, old code, or multiple deployed versions must coexist during change, report a migration-engineering concern.