Home/DDL ↔ Entity
DB

DDL ↔ Entity

Convert SQL CREATE TABLE to entity classes and back for 7 languages

Direction
Options
SQL DDLSQL
Entity classJAVA

Overview: DDL ↔ Entity converts a SQL CREATE TABLE statement into an entity / model class in Java, C#, Python, Go, TypeScript, C++ or JavaScript, and can also parse an entity class back into a DDL statement for MySQL, PostgreSQL or SQLite. It saves you from writing repetitive mapping code between the database schema and application code.

How to use: Step 1 - choose a direction: DDL -> Entity or Entity -> DDL. Step 2 - pick the target language and SQL dialect. Step 3 - toggle ORM annotations, Lombok, and column comments as needed, and fill in the package or namespace. Step 4 - paste your source into the appropriate panel; the other panel updates automatically. Use the Sample button to load a demo table.

Typical scenarios: Back-end developers turning DBA-provided DDL into JPA / Entity Framework / GORM entity classes; front-end and full-stack teams generating strongly-typed TypeScript models directly from database schemas; data engineers reverse-engineering DDL from struct or dataclass definitions when bootstrapping a new environment; teams standardising the mapping between snake_case columns and camelCase / PascalCase fields.

Technical notes: The DDL parser understands common column definitions - VARCHAR(n), DECIMAL(p,s), BIGINT, TINYINT(1), DATETIME, JSON and so on - and normalises them to a language-agnostic type set. The reverse pass reads the entity class with a lightweight parser and rebuilds the DDL with dialect-specific tweaks (AUTO_INCREMENT vs SERIAL, TINYINT(1) vs BOOLEAN, BYTEA vs BLOB, etc.). Column names are converted to snake_case and field names to PascalCase / camelCase automatically.

Privacy: Parsing and code generation both run entirely in your browser; no DDL or entity code is uploaded to any server, so it is safe to use with schemas that contain business-sensitive table or column names.

Frequently Asked Questions

How do I use DDL ↔ Entity?
Step 2 - pick the target language and SQL dialect. Step 3 - toggle ORM annotations, Lombok, and column comments as needed, and fill in the package or namespace.
What can DDL ↔ Entity do?
Typical scenarios: Back-end developers turning DBA-provided DDL into JPA / Entity Framework / GORM entity classes; front-end and full-stack teams generating strongly-typed TypeScript models directly from database schemas; data engineers…
Is my data private when I use DDL ↔ Entity?
Privacy: Parsing and code generation both run entirely in your browser; no DDL or entity code is uploaded to any server, so it is safe to use with schemas that contain business-sensitive table or column names. Privacy: Parsing and code generation both run entirely in your browser; no DDL or entity code is uploaded to…
What technical details should I know about DDL ↔ Entity?
Technical notes: The DDL parser understands common column definitions - VARCHAR(n) , DECIMAL(p,s) , BIGINT , TINYINT(1) , DATETIME , JSON and so on - and normalises them to a language-agnostic type set. Technical notes: The DDL parser understands common column definitions - VARCHAR(n) , DECIMAL(p,s) , BIGINT…