{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Dialect{{ dialectLabel }} Relationships{{ resultsReady ? computation.values.relationship_count : '—' }} Status{{ resultsReady ? 'Valid model' : 'Review needed' }}
Choose the engine that will receive the reviewed script.
Letters, numbers, and underscores; start with a letter or underscore.
Tables:
The starter model demonstrates primary keys, a unique email, defaults, and one owner relationship. Replace sample names before use.
Paste a model previously downloaded from this tool. Embedded DDL is ignored and regenerated locally.
ColumnTypeLengthConstraintsForeign keyOn deleteRemove
The neutral default is off. Opening Advanced alone does not change the DDL.
{{ computation.values.ddl }}

{{ ddlExportStatus }}

{{ chartExportStatus }}

The chart renderer is unavailable. The same counts remain available in the table catalog.

TableColumnsPrimary keysForeign keysUniqueCreate orderCopy
{{ row.table }}{{ row.columns }}{{ row.primary_keys }}{{ row.foreign_keys }}{{ row.unique_constraints }}{{ row.create_order }}

{{ tableExportStatus }}

SQLite Manager Open a SQLite file in your browser and inspect schema or rows before running guarded SQL and saving deliberate edits as a new local copy.
SQL INSERT Generator Turn pasted rows or a local delimited file into reviewable SQL INSERT statements with dialect-aware identifiers, literal handling, and row checks.
SQL Formatter Format SQL in your browser with dialect-aware layout and an audit that flags fallback output, unbalanced parentheses, and risky reuse.
JSON Schema Generator Turn sample JSON into a draft-aware JSON Schema with explicit inference choices and review warnings for assumptions that need broader test data.

A relational schema is the agreement between stored data and every query, form, report, and service that depends on it. Tables define the main entities, columns define the facts each row may hold, and constraints keep invalid or contradictory rows from becoming normal data.

Good schema work starts with relationships and rules, not with SQL syntax. A primary key gives each row a stable identity. A foreign key connects a child row to an existing parent. NOT NULL distinguishes required data from missing data, while UNIQUE prevents duplicate values where the business rule requires one owner or one code.

Decision Question It Answers Consequence of Getting It Wrong
Table boundary Which facts belong to one entity or repeating relationship? Duplicated data becomes harder to update consistently.
Column type and nullability What values are valid, and may the fact be absent? Applications must guess at meaning or accept values they cannot use.
Primary and unique keys How is a row identified, and which values must not repeat? Updates can target the wrong row and duplicates can undermine identity.
Foreign key action What happens to child rows when a parent is deleted? CASCADE can remove more data than intended, while RESTRICT can block a required cleanup.

Data definition language (DDL) expresses these choices for a database engine, but PostgreSQL, MySQL, and SQLite do not use identical types, identity syntax, identifier quoting, or foreign-key behavior. A portable model is therefore a useful starting point rather than a promise that one script captures every engine feature.

Generated DDL still deserves a migration review. Check defaults, destructive statements, indexes, naming conventions, character sets, collations, engine settings, existing data, and rollback plans in the environment that will actually run it.

How to Use This Tool:

Model the smallest complete set of tables first, then review the generated script as engine-specific DDL rather than executable approval.

  1. Choose PostgreSQL 18, MySQL 8.4, or SQLite 3 under SQL dialect, and give the model a portable Schema model name.
  2. Add each table and its columns. Use names that begin with a letter or underscore and contain only letters, numbers, and underscores.
  3. Choose a portable column type, set a VARCHAR length where required, and mark primary key, nullability, uniqueness, identity, and default-expression rules.
  4. Add each foreign key by selecting a primary-key or unique target with the same portable type and length. Choose the intended On delete action; Set null requires a nullable child column.
  5. Correct the first validation message before relying on the DDL. Missing primary keys, duplicate names, incompatible references, and cross-table dependency cycles prevent generation.
  6. Review DDL script and Table catalog together. Confirm table creation order, constraints, defaults, and relationship counts before copying the SQL into a migration.
  7. Enable Include DROP TABLE guards only for a deliberate rebuild. The option prepends destructive statements in reverse dependency order.

Interpreting Results:

A generated script means the model passed the portable rules described below. It does not prove that the target database is empty, that existing data satisfies the constraints, or that application queries have the indexes they need.

The create order places referenced tables before their dependent tables. A self-reference can remain inside one table definition, but a cycle between separate tables is rejected because a one-pass sequence cannot create both inline foreign keys before both tables exist.

Treat the table and relationship counts as a review aid, not a quality score. A small schema can still be wrong, and a larger schema can be coherent when each table has a clear responsibility.

Technical Details:

The model uses a deliberately narrow relational subset so the same table design can be projected into three SQL dialects. Validation happens before projection because quoting invalid names or rendering incompatible foreign keys would only produce SQL that fails later.

Transformation Core:

Stage What Happens Result
Normalize Identifiers are trimmed, Boolean choices are normalized, and column, constraint, and reference fields are placed in a stable model. One consistent representation for validation and import.
Validate Names, counts, types, primary keys, defaults, foreign-key targets, type compatibility, and delete actions are checked. Invalid models stop before any DDL is treated as ready.
Order dependencies Each table points to the non-self tables it references, and a dependency walk places parents before children. A stable one-pass CREATE TABLE order and reverse drop order.
Project dialect Identifiers, portable types, identity columns, foreign-key actions, and supporting statements are rendered for the selected engine. PostgreSQL 18, MySQL 8.4, or SQLite 3 DDL.

Rule Core:

Rule Accepted Boundary Reason
Tables1 to 12, with unique names and stable identifiers.Bounds the local model and prevents ambiguous DDL.
Columns per table1 to 30, with unique names and at least one primary-key column.Every table needs identity and unambiguous column references.
Identifiers1 to 63 characters; first character is a letter or underscore, followed by letters, numbers, or underscores.The portable rule avoids engine-specific quoting and length surprises.
VARCHAR lengthWhole number from 1 through 65,535.The selected portable type requires an explicit length.
Identity columnAt most one per table; it must be an integer primary key, and the table must have no other primary-key columns.Keeps PostgreSQL identity, MySQL auto-increment, and SQLite row identity compatible.
Default expressionUp to 160 characters, with no semicolon, null byte, or SQL comment delimiter.The expression remains a single reviewable clause; its engine semantics still need review.
Foreign keyOne source column to a primary-key or unique target with the same portable type and length.Prevents missing, non-unique, and mismatched targets.
Delete actionNO ACTION, RESTRICT, CASCADE, or SET NULL.SET NULL is rejected unless the child column is nullable.

Dialect Projection:

Dialect Identity and Types Relationship Handling
PostgreSQL 18 Double-quoted identifiers and GENERATED BY DEFAULT AS IDENTITY; portable types map to native PostgreSQL types. Named inline foreign keys are emitted, followed by an index for each referencing column.
MySQL 8.4 Backtick-quoted identifiers, INT, and AUTO_INCREMENT. Named inline foreign keys are emitted without separate CREATE INDEX statements.
SQLite 3 Double-quoted identifiers; several portable types map to INTEGER, TEXT, or NUMERIC. Identity uses INTEGER PRIMARY KEY AUTOINCREMENT. PRAGMA foreign_keys = ON precedes the tables, and referencing columns receive separate indexes.

A users table referenced by projects.owner_id illustrates the ordering rule. The matching primary key is created first, the child table follows with its foreign key and delete action, and PostgreSQL or SQLite then receives an index for the child reference column.

Limitations and Review Notes:

The generated script covers a portable design subset. It does not inspect a live database, plan a data migration, test queries, or include every engine feature.

  • The schema model name labels the design; it does not create or qualify a database schema namespace in the DDL.
  • Defaults are screened for delimiters and comments but are still SQL expressions that must be reviewed for the selected engine.
  • Foreign keys are single-column relationships. Check constraints, partial indexes, collations, generated columns, storage engines, and engine-specific options are outside the model.
  • DROP TABLE guards are destructive. Review backups, dependencies outside this model, and rollback steps before running them.
  • Run the final script in a disposable or staged database and inspect the stored schema before production use.

References: