「とりあえずCREATE TABLE文が欲しい」を最速で

新しい機能を作り始めるとき、頭の中にはだいたいのテーブル構成のイメージがあります。それをCREATE TABLE文として書き下すのは単純作業ですが、意外と時間を取られます。カラムの型を毎回思い出したり、MySQLとPostgreSQLで書式が違うのを調べ直したり、外部キーの構文を間違えたり——。

テーブル設計からCREATE TABLE文を自動生成する仕組み｜DDLビルダー

DDLビルダー は、テーブルとカラムを画面上で組み立てるだけで、MySQL / PostgreSQL / SQLiteそれぞれの書式に沿ったCREATE TABLE文と、Mermaid形式のER図を同時に生成するツールです。JSONサンプルを貼り付ければ、カラム構成を自動推測することもできます。すべてブラウザ内で処理され、入力したテーブル設計は外部に送信されません。

この記事では、ツールの内部で何が起きているか——型がどう変換されるかとJSONからどうやってカラムを推測しているかを実装ベースで解説します。

3つの入力方法

DDLビルダーには、テーブルを作る方法が3つあります。

  1. JSONから自動生成: APIレスポンスやログのJSONサンプルを貼り付けると、カラム名・型・主キー・NOT NULLを自動推測してテーブルを追加します。
  2. 手動でのテーブル設計: テーブル名・カラム名・型・PK/NOT NULL/UNIQUE/自動採番・デフォルト値を画面上で直接編集します。
  3. リレーション: 参照元テーブル・カラムと参照先テーブル・カラムを選ぶだけで、外部キー制約とER図の関連線が追加されます。

生成したDDLは、Visual SQL Builder にそのまま引き継いでクエリ作成に進めたり、後日 SQL to ER図 変換 に貼り付けて構成を見直したりできます。設計からクエリ作成までの一連の流れがブラウザ内だけで完結する構成です。

型はデータベースごとにどう変換されるか

ツールは内部的に、データベースに依存しない共通の「論理型」でテーブルを管理しています。

export type LogicalType =
    | 'INTEGER' | 'BIGINT' | 'DECIMAL' | 'VARCHAR' | 'TEXT'
    | 'BOOLEAN' | 'DATE' | 'DATETIME' | 'JSON' | 'UUID';

DDLを生成するタイミングで、選んだ方言に応じて実際のSQL型に変換します。特徴的なのは、SQLiteに真偽値型・JSON型が無いための変換と、主キーの自動採番構文の違いです。

論理型MySQLPostgreSQLSQLite
BOOLEANBOOLEANBOOLEANINTEGER
JSONJSONJSONBTEXT
UUIDCHAR(36)UUIDTEXT
PK + 自動採番INT ... AUTO_INCREMENTSERIALINTEGER PRIMARY KEY AUTOINCREMENT

主キー＋自動採番の行が特に方言差が大きい部分です。PostgreSQLは型そのものがSERIAL（内部的にはINTEGER+シーケンス）に置き換わり、SQLiteはINTEGER PRIMARY KEYという特定の書き方をしたときだけ本物のrowid別名として自動採番になる、という仕様上の制約があります。ツールはこの3方言の違いを吸収して、選んだ方言に応じた正しい構文を出力します。

なお、主キーに指定したカラムはNOT NULL・UNIQUE・デフォルト値の指定があっても無視され、<型> PRIMARY KEYとしてのみ出力されます。主キーは定義上すでにNOT NULLかつUNIQUEだからです。

JSONサンプルからカラムを推測するロジック

JSONオブジェクト（または配列）を貼り付けると、各プロパティの値からカラムの型を推測します。判定の優先順位はおおよそ次の通りです。

  1. 値が真偽値のみ → BOOLEAN
  2. 値が数値のみ → 整数ならINTEGER（2^31を超えるものがあればBIGINT）、小数を含むならDECIMAL
  3. 値が文字列のみ → ISO 8601の日時形式ならDATETIME、日付形式ならDATE、UUID形式ならUUID、それ以外はVARCHAR（255文字を超えるものがあればTEXT）
  4. 値がオブジェクトのみ → JSON

配列でサンプルを渡した場合は、複数件の値をまとめて判定に使います。これにより、1件だけでは分からないNULL許容（値にnullが混ざっているか）や、型のばらつき（整数だけでなく小数も混ざっている、など）を検出できます。

[
  { "id": 1, "nickname": "Alice", "score": 10 },
  { "id": 2, "nickname": null, "score": 10.5 }
]

このサンプルでは、nicknameにNULLが混ざっているためNOT NULLを外し、scoreは整数と小数が混在しているためDECIMALとして推測されます。

ネストしたオブジェクトの配列は関連テーブルに分割される

トップレベルのプロパティが「オブジェクトの配列」の場合は、単純にJSON型のカラムにするのではなく、親テーブルへの外部キーを持つ別テーブルとして自動的に切り出します。

{
  "id": 1,
  "name": "Order #1",
  "items": [
    { "product": "Widget", "qty": 2 },
    { "product": "Gadget", "qty": 1 }
  ]
}

このJSONをordersという名前で生成すると、ordersテーブルとは別にitemsテーブルが作られ、items.orders_id → orders.idという外部キー関係が自動的に設定されます。注文とその明細行のような1対多の関係を、JSON1つから組み立てられる形です。ネストが2階層より深い場合は自動でテーブル分割されないため、その場合は生成後に手動で調整してください。

SQL to ER図 変換との往復で設計を確認する

DDLビルダーで作ったテーブル構成をMySQL方言のDDLとして書き出し、それを SQL to ER図 変換 に貼り付けると、パース結果として同じテーブル・カラム・関係が再現されます。生成したDDLがきちんとパース可能な標準的な構文になっているかを確認したいときや、後から構成を見直すときに使える往復ルートです。

よくある質問

PKにチェックを入れると、NOT NULL・UNIQUE・デフォルト値の指定はどうなりますか？

主キーは仕様上NOT NULLかつUNIQUEを含むため、PKにチェックを入れたカラムではNOT NULL・UNIQUE・デフォルト値の指定は無視され、「型 PRIMARY KEY」（自動採番がONならAUTO_INCREMENT等を付加）としてのみ出力されます。

生成したDDLをそのまま本番のマイグレーションに使ってよいですか？

このツールはテーブル設計の叩き台やレビュー資料として使うことを想定しています。インデックス、CHECK制約、文字コード・照合順序、パーティショニングなど本番運用で必要になる詳細は含まれないため、生成後は必ず内容を確認し、必要な調整を加えてから使用してください。

JSONから生成したテーブル名が既存のテーブルと重複したらどうなりますか？

自動的に_2のような連番を付けて重複を避けます。手動で作った既存のテーブルが上書きされることはありません。

テーブル設計に迷ったら、まずは手元のJSONサンプルを貼り付けてみてください。

DDLビルダーを使ってみる

他にも開発で使える便利ツールを公開しています。
https://devtoolkits.app/