What is proper approach to code first entity relationship design?

Question

I been trying to figure out, what i hoped is a simple problem, but am yet to land with an answer.

How do you go about designing an entity relationship diagram when doing code first development?

The people I've spoken to and things I've seen on google usually refer to the approach of designing for a specific db type (e.g. PostgreSQL, MSSQL, etc.) then working backwards. To me it doesn't make sense doing it this way, as I've always seen code-first design being an essentially a abstraction i.e. you design the pattern, and you let the code figure out the rest, which is the direction I see software engineering going towards faster and faster.

Is there a proper approach to this? If so what is that approach? What is proper approach to code first entity relationship design?

Answer 1

It does not matter if you create a db schema by a code-first approach of some ORM, or by bare SQL statements. Once you have a schema in your favorite database, you can always reverse-engineer it into your favorite ER diagramming tool.

How you do this exactly depends heavily on the specific tooling of your choice. Commercial tools often support reverse-engineering with updates for an evolving schema. There are also some useable freeware tools available today, and if the reverse engineering capabilities of those are not sufficient, you can also implement your own tool (for example, we did something like that in the past by implementing a generator which reads a DB schema and creates SVG files for further processing in Inkscape).

You have to check if the reverse-engineering (and specificially the repeated reverse-engineering for an evolving schema) gives you satisfying results for your case. But expect this to be a semi-automatic process, I have actually never seen any ER diagramming software which creates useable diagram layouts in a completely automatic fashion.