ER-Diagramm aus SQL generieren, das mit deinem Schema synchron bleibt

Jedes Schema-Diagramm fängt wahr an und endet als Lügner. Jemand zeichnet es in der Woche vor dem Launch, es bekommt einen Ehrenplatz im Wiki, und dann wird das Produkt ausgeliefert. Zwanzig Migrationen später zeigt es immer noch eine users-Tabelle ohne deleted_at, eine orders-Tabelle, die inzwischen zweigeteilt wurde, und eine Beziehung, die im März wegrefaktoriert wurde. Neue Engineers lesen es, glauben es und bauen auf dem Bild einer Datenbank auf, die es nicht mehr gibt.

Die übliche Reaktion ist schlechtes Gewissen: Wir hätten es aktuell halten sollen. Aber ein Diagramm nach jeder Migration von Hand zu aktualisieren, ist eine undankbare Pflicht, also passiert es nie. Die dauerhafte Lösung ist, zu ändern, woher das Diagramm kommt. Wenn es aus dem Schema generiert wird, statt daneben gepflegt zu werden, ist Drift unmöglich, denn das Bild ist immer eine Ansicht der aktuellen Wahrheit.

Behandle das Diagramm als abgeleitet, nicht als verfasst

Dein Schema lebt bereits an einem kanonischen Ort: in den Migrationen, die du ausführst, und in der DDL, die du aus jeder Umgebung dumpen kannst. Das ist die Quelle der Wahrheit, und sie ist maschinenlesbar. Ein von Hand gepflegtes Diagramm ist eine zweite Kopie dieser Wahrheit, und zwei Kopien von irgendetwas driften auseinander. Also macht man das Diagramm zu einer Projektion des Schemas, so wie ein Bericht eine Projektion einer Tabelle ist: bei Bedarf neu erzeugt, nie bis zur Veraltung bearbeitet.

In der Praxis heißt das: Wann immer du das aktuelle Bild willst, gibst du das aktuelle Schema hinein und bekommst das Diagramm heraus. Kein manueller Abgleich, kein "wer hat das zuletzt angefasst", keine veralteten Beziehungen.

ER-Diagramm aus der DDL, die du ohnehin dumpst

Du brauchst keinen speziellen Export. Jede Datenbank kann dir ihr Schema als SQL ausgeben, und genau dieses SQL liest LetDraw. Bei Postgres ist es ein einziger Befehl; MySQL und andere haben ihre eigenen Entsprechungen.

# Postgres: dump just the schema, no data
pg_dump --schema-only --no-owner mydb > schema.sql

# then: Generate from Code → paste schema.sql → get the ER diagram

Öffne den Dialog "Aus Code generieren", füge die Datei ein, und LetDraw baut das Diagramm: Tabellen mit typisierten Spalten, markierte Primär- und Fremdschlüssel sowie 1:n-Linien, die aus den REFERENCES-Klauseln mit sauberen Krähenfuß-Enden gezeichnet werden. Was einen Nachmittag Rechtecke-Schieben gekostet hat, ist jetzt ein Einfügen, und weil es aus der echten DDL stammt, ist es konstruktionsbedingt korrekt.

Ein Diagramm, das du in zehn Sekunden neu generierst, veraltet nie, weil niemand daran denken muss, es zu aktualisieren.

Bau es in den Workflow ein, damit es nie driftet

Sobald das Generieren des Diagramms billig ist, kannst du es dort platzieren, wo es ehrlich bleibt. Ein paar Gewohnheiten, die Drift strukturell unmöglich machen:

• Bei jedem Release neu generieren. Nimm "ER-Diagramm aus schema.sql aktualisieren" in deine Release-Checkliste auf. Diesen Satz zu lesen dauert länger, als es zu tun.
• Vergleichen statt neu zeichnen. Wenn eine Migration landet, generiere ein frisches Diagramm und vergleiche. Neue Tabelle, neue Spalte, geänderter Schlüssel: Die Änderung ist sichtbar, und du behältst die Anmerkungen, die du von Hand an den unveränderten Teilen hinzugefügt hast.
• Auf die Änderung beschränken. Füge in einem Review nur die Tabellen ein, um die es geht. Ein fokussiertes ER-Diagramm mit sechs Tabellen, das nachweislich aktuell ist, schlägt ein Poster mit vierzig Tabellen, das es vielleicht ist.
• Behalte es auch als Code. Wandle das Diagramm zurück in Mermaid oder D2 und committe es neben der Migration, damit das Bild mit der Änderung im selben Pull Request reist.

Bei einem Schema-Diagramm geht es um Vertrauen

Ein Schema-Diagramm verdient seinen Platz erst, wenn Leute ihm glauben, ohne nachzuprüfen. Dieses Vertrauen gewinnt man nicht durch Disziplin, sondern indem man den menschlichen Schritt entfernt, der schiefgeht. Generiere das Bild aus der DDL, die du ohnehin pflegst, aktualisiere es, wann immer sich das Schema bewegt, und das Diagramm ist kein Museumsstück mehr, sondern etwas, zu dem das Team tatsächlich greift. Konstruktionsbedingt korrekt, standardmäßig aktuell.

Dumpe dein Schema, füge es einmal ein und sieh, wie nah dein mentales Modell an der Datenbank ist, die du tatsächlich betreibst.