Problem
The ER diagram only renders one kind of relationship. In ERDiagramModels.swift the ERCardinality enum has a single case manyToOne, so 1:1, 1:N, and N:N relationships all look the same on the canvas. Junction tables that imply many-to-many links are not detected either. This makes the diagram hard to use when reviewing a real schema.
There is also no way to turn the diagram back into SQL. After arranging tables and looking at relationships, the user still has to write the CREATE TABLE and FOREIGN KEY statements by hand.
Proposed solution
- Distinguish relationship types on edges: one-to-one, one-to-many, many-to-one, many-to-many. Use unique columns / primary key info to infer 1:1 vs 1:N, and detect junction tables (two FKs that together form the PK) as M:N.
- Render each type with a different edge marker (crow's foot or similar) so the relationship is readable at a glance.
- Add an "Export as SQL" action in the diagram toolbar that emits
CREATE TABLE statements plus FOREIGN KEY constraints for the current diagram, targeting the active database dialect.
Alternatives considered
- Exporting the diagram as an image (already supported) does not help when the user wants to recreate the schema elsewhere.
- Copying DDL from each table tab one by one works but is slow and loses the relationship overview the diagram provides.
Related database type
N/A / General
Reported by a user (translated from Vietnamese): the diagram does not show all relationships, and a diagram-to-code option would be useful.
Problem
The ER diagram only renders one kind of relationship. In
ERDiagramModels.swifttheERCardinalityenum has a single casemanyToOne, so 1:1, 1:N, and N:N relationships all look the same on the canvas. Junction tables that imply many-to-many links are not detected either. This makes the diagram hard to use when reviewing a real schema.There is also no way to turn the diagram back into SQL. After arranging tables and looking at relationships, the user still has to write the
CREATE TABLEandFOREIGN KEYstatements by hand.Proposed solution
CREATE TABLEstatements plusFOREIGN KEYconstraints for the current diagram, targeting the active database dialect.Alternatives considered
Related database type
N/A / General
Reported by a user (translated from Vietnamese): the diagram does not show all relationships, and a diagram-to-code option would be useful.