diagram2codeConvert PlantUML to MySQL
Generate production-ready MySQL SQL code from your PlantUML diagrams in seconds.
How the PlantUML to MySQL conversion works
PlantUML entity diagrams are the standard in many enterprise and Java-adjacent teams, with first-class tooling in IDEs and Confluence. Entities declare mandatory fields with a leading *, and stereotypes like <<FK>> mark key columns.
Entities are `entity Name { … }` blocks — a leading `*` marks mandatory (NOT NULL) fields, `<<FK>>` marks foreign keys, and relationships use the same cardinality arrows as Mermaid (`User ||--o{ Post`). Quoted display names (`entity "User Account" as ua`) become table comments.
Paste your PlantUML source into the editor above and the engine parses it into an
intermediate schema — tables, columns, relationships, indexes — then generates
MySQL DDL from that model. Anything the diagram
syntax can't express (NOT NULL, defaults, enums, CHECK constraints, composite indexes)
you add with comment directives like ' ::NN, ::DEFAULT(now()) on the line
above a column. The PlantUML reference documents the
full vocabulary.
What the generator emits for MySQL
- CREATE TABLE statements with backtick-quoted identifiers, ready for InnoDB
- AUTO_INCREMENT primary keys for single integer PK columns
- inline ENUM(…) column types for ::ENUM(...) columns
- ALTER TABLE … ADD CONSTRAINT foreign keys with ON DELETE / ON UPDATE actions
- inline COMMENT column options and COMMENT = table options
- CREATE INDEX / CREATE UNIQUE INDEX for composite and named indexes
Type mapping: PlantUML to MySQL
Diagram column types are logical — the generator maps each one to the idiomatic MySQL type. These are the exact mappings the engine uses:
| Diagram type | MySQL type | Notes |
|---|---|---|
int | INT | INT AUTO_INCREMENT when it is the auto-increment primary key |
string | VARCHAR(255) | use varchar(n) in the diagram to control length |
text | TEXT | longtext / mediumtext map to their native equivalents |
decimal | DECIMAL | decimal(10,2) passes precision through |
boolean | TINYINT(1) | the MySQL convention for booleans |
date | DATE | |
timestamp | DATETIME | |
uuid | CHAR(36) | stored as the canonical text form |
bigint | BIGINT | |
blob | BLOB |
Keys, relationships, and enums
A single `int id PK` column becomes `` `id` INT AUTO_INCREMENT PRIMARY KEY ``. Composite primary keys emit a table-level `PRIMARY KEY (a, b)` without auto-increment.
Relationships emit `ALTER TABLE … ADD CONSTRAINT` statements with deterministic `fk_<table>_<column>` names — important on MySQL, where anonymous constraints make later migrations painful. ON DELETE / ON UPDATE actions come from the ::RELATIONSHIP directive.
MySQL supports enums natively on the column, so `::ENUM(active, inactive)` emits `status ENUM('active', 'inactive')` inline — no separate type object, no CHECK constraint.
Frequently asked questions
Does the generated MySQL DDL use native ENUM columns?
Yes. ::ENUM(...) values are emitted as an inline ENUM(…) column type, which MySQL validates at the storage layer. PostgreSQL output uses CREATE TYPE instead; SQLite and Oracle fall back to CHECK constraints.
How are booleans represented?
As TINYINT(1), the MySQL convention. Most drivers and ORMs read TINYINT(1) back as a boolean automatically.
Are identifiers quoted for MySQL?
Yes — with backticks. A table named `order` (a reserved word) generates valid DDL because every identifier is backtick-quoted.
Why are foreign keys added with ALTER TABLE instead of inline REFERENCES?
Adding constraints after all CREATE TABLE statements makes the DDL order-independent — a child table can be declared before its parent in the diagram and the script still runs cleanly.