ORM-Modelle aus SQL erzeugen

Fügen Sie Tabellendefinitionen ein und wählen Sie das ORM. Passen Sie den Modellentwurf und anwendungsspezifische Zuordnungen vor der Nutzung an.

Läuft lokal in deinem Browser
Dieses Werkzeug verarbeitet alle Daten lokal in deinem Browser.
SQL-DDLFügen Sie CREATE-TABLE-Anweisungen aus MySQL, PostgreSQL, SQLite oder SQL Server ein. Der Parser liest Tabellen, Spalten, Primärschlüssel und direkte REFERENCES-Klauseln.
Erzeugte Modelle

CREATE-TABLE-Anweisungen in ORM-Modelle umwandeln

CREATE-TABLE-Anweisungen einfügen, Prisma, Drizzle, TypeORM oder SQLAlchemy wählen und „Modelle erzeugen“ drücken. Jede Tabelle im Text wird gelesen — Spalten, Typen, NOT NULL, Primärschlüssel, Standardwerte und Fremdschlüssel — und das Ergebnis enthält einen Modellblock pro Tabelle zum Kopieren oder Herunterladen.

Alles läuft in der Seite: Beim Erzeugen der Modelle ging im Test keine Netzwerkanfrage raus, das Schema verlässt also den Browser nicht und das Werkzeug arbeitet auch ohne Verbindung weiter.

  1. Die DDL in das Feld „SQL-DDL“ einfügen oder „Beispiel laden“ drücken, um mit zwei kleinen Tabellen zu starten.
  2. Unter „Erzeugen für“ das Ziel wählen: Prisma, Drizzle ORM, TypeORM oder SQLAlchemy.
  3. „Modelle erzeugen“ drücken. Die Statuszeile nennt die Anzahl der erzeugten Tabellenmodelle und weist darauf hin, wenn eine Definition im eingefügten DDL nicht gelesen werden konnte.
  4. Das Ziel jederzeit wechseln: Die Ausgabe wird neu erzeugt und passt damit immer zum daneben angezeigten ORM.
  5. Mit „Kopieren“ oder „Herunterladen“ (models.ts, bei SQLAlchemy models.py) den Code mitnehmen und mit „Leeren“ beide Felder zurücksetzen. Wird kein CREATE TABLE gefunden, bleibt die Ausgabe leer und „Kopieren“ meldet, dass es nichts zu kopieren gibt.

Wie das DDL gelesen wird und was die Modelle enthalten

Was der Parser liest

Tabellennamen mit oder ohne Schema-Präfix (app.accounts wird als accounts ausgegeben), Spaltennamen in Backticks, doppelten Anführungszeichen oder Klammern und den Typ jeder Spalte. NOT NULL macht ein Feld erforderlich, eine nullable Spalte optional. Primärschlüssel kommen aus einem spaltenweiten PRIMARY KEY und aus einem tabellenweiten PRIMARY KEY (a, b), zusammengesetzte Schlüssel eingeschlossen.

Auto-Inkrement stammt aus dem DDL und nicht aus dem Spaltennamen: SERIAL, BIGSERIAL, AUTO_INCREMENT, GENERATED … AS IDENTITY und ein nextval(…)-Standard werden erkannt, ein einfacher PRIMARY KEY bleibt ein gewöhnlicher Schlüssel. DEFAULT CURRENT_TIMESTAMP und now() werden zum jeweiligen „now“-Standard des Ziels. Fremdschlüssel werden sowohl aus REFERENCES auf Spaltenebene als auch aus CONSTRAINT … FOREIGN KEY auf Tabellenebene gelesen. Zeilenkommentare (-- und # aus MySQL) und Blockkommentare werden vor dem Parsen entfernt.

Was die einzelnen Ziele ausgeben

Prisma: ein Modell pro Tabelle mit @id, @@id([...]) bei mehrspaltigen Schlüsseln, @default(autoincrement()) nur dort, wo das DDL es erklärt, @default(now()) für aktuelle Zeitstempel, @db.Uuid für UUID-Spalten sowie @map / @@map, damit die erzeugten Namen weiter auf die ursprünglichen SQL-Namen zeigen.

Drizzle ORM: pgTable-Deklarationen für den Postgres-Dialekt, bei zusammengesetzten Schlüsseln mit primaryKey({ columns: [...] }). TypeORM: @PrimaryGeneratedColumn nur für Auto-Inkrement-Spalten und @PrimaryColumn für alle anderen Schlüssel, damit die Dekoratoren zum Schema passen. SQLAlchemy: Klassen im 2.0-Stil mit DeclarativeBase, Mapped[...]-Annotationen, mapped_column() und ForeignKey('tabelle.spalte') für beide Fremdschlüssel-Schreibweisen; die Importliste enthält nur, was die Modelle nutzen.

Vor der Weiterverwendung prüfen

Die Typzuordnung ist bewusst grob. varchar, char, text und citext werden zum String-Typ des Ziels, DECIMAL und NUMERIC zu einer Dezimalspalte mit der Annotation Decimal, JSON, JSONB und XML nutzen den generischen JSON-Typ, und ein unbekannter Typ fällt auf string zurück. Vergleichen Sie eine repräsentative Tabelle mit dem echten Schema, bevor Sie daraus Migrationen erzeugen.

Alles, was keine Spalte ist, bleibt in der Datenbank: CHECK, UNIQUE, Indizes, Views, Trigger, Sequenzen, Collations und Storage-Klauseln werden nicht übernommen, und kein Ziel erhält Beziehungs- oder Navigationsobjekte — ein Fremdschlüssel bleibt überall eine einfache Spalte, außer in SQLAlchemy, wo ForeignKey hinzukommt. Die Drizzle-Ausgabe bleibt am Postgres-Dialekt, unabhängig vom Dialekt des eingefügten DDL.

Zuletzt verwendet: