> entities are fundamentally different from tables

Isn't the fact that they are _mostly_ interchangeable the foundational principle of hundreds of ORMs? Of course the DDL doesn't say much about the entity's lifecycle, but if the bar is set at representing its relationships, fields and cardinality as a graph, it seems sufficient?

I think most successful ORMs have an additional layer of semantics beyond what can be directly expressed in SQL. For example, Active Record has multiple types of associations (belongs_to, has_one, has_many, etc.) that I would argue align more closely to the ER model than the relational model. Of course you can come up with a set of conventions to go from ER to relational when everything is fed through the ORM, but you are losing some semantic information in the process. (That is, if you just look at the SQL table definitions, you don't have the same information about relationships).

ORMs are on a poor foundation. But I don't see the problem with this tool, it's just showing the tables.

I don't see a problem with the tool either really, it's just a pet peeve of mine to call what it produces an ER diagram when it's really a diagram of the relational model defined by the SQL.

To make parent’s point more exact: from Chen’s definition, these ER diagrams derived from SQL are the “physical” (most low-level) diagrams, you cannot recreate the “logic” or “conceptual” diagrams from it.

I guess nowadays few people care about this difference.

Few people ever cared about the difference.

the use case for sql to er, is to study a database new to you

so the db already exist, but they have no er, and maybe even little docs

so it act more like an exploratory tool, ideally, it should allow you to create views and add notes, so you dont have to look at the full er at once, especially if the number of table is huge, and if many of those tables are missing foreign keys

Can you please elaborate on the differences? They are practically interchangeable, but conceptually there might be another layer on top of entities and relationships for somewhat richer semantics (like describing a relation, or additional annotations on the entity)

One example is that in ER cardinality is specified on the relation. In SQL cardinality is implemented and can be largely reversed to ER by looking at where foreign keys are.

Many to many will lead to an extra table (which can have additional properties, requiring this table to be modelled as an entity), one to many leads to the inclusion of a foreign key to another unique key (referring all columns of that key, _id is an implementation decision, compound primary keys are possible). One to one can be implemented in multiple ways, like one to many with a uniqueness constraint by the referring table or even by merging entities to a single table.

The raw SQL can be revealing but when entities have merged into one table it’s harder to tell what is what, unless a certain set of columns appears over different tables.

Aside from what else is mentioned in the sibling comment, inheritance is another big one. Inheritance is not explicit in SQL and in fact, when going from ER to SQL, there are multiple choices you can make about how to materialize the inheritance hierarchy.

Another is that in ER diagrams, relationships themselves can have attributes. Personally I think it tends to make more sense to convert relationships to entities in this case most of the time, but it can be useful.

Finally, relationships in ER diagrams can be N-ary and connect more than two entities while foreign keys in SQL always reference one other table. Of course you can have multiple foreign keys on a table to represent this, but not without some loss of semantics.

Can you please elaborate? My understanding was that entities always have a 1:1 relationship with tables.

An example would be really helpful.

Inheritance is one case. In an ER diagram, you may have Employee and Client entities which both inherit from a Person entity. You could choose to have these represented as a single table (with nullable fields where not relevant). They could be three completely separate tables with common fields duplicated across the tables. Or there could be three tables where one table has the common fields from Person with Employee and Client having foreign keys to this table along with whatever unique fields they have.

> entities are fundamentally different from tables

one man’s simplicity is another man’s headache