本文へスキップ
DB設計

DDLビルダー

テーブルをビジュアルに設計して、CREATE TABLE文(MySQL / PostgreSQL / SQLite)とER図を同時に生成します。JSONサンプルを貼り付ければカラムを自動推測することもできます。処理はすべてブラウザ内で完結し、入力内容は送信されません。

ガイド: 使い方・特徴

  • 「JSONから自動生成」にオブジェクトまたは配列のJSONを貼り付けて生成すると、カラムの型・主キー・NOT NULLが自動推測された状態でテーブルが追加されます。
  • 「テーブル設計」ではテーブル名・カラム名・型・PK/NOT NULL/UNIQUE/自動採番・デフォルト値を画面上で直接編集できます。
  • 「リレーション」で参照元テーブル・カラムと参照先テーブル・カラムを選ぶと、外部キー制約とER図の関連線が追加されます。
  • 方言(MySQL / PostgreSQL / SQLite)を選んで「DDLを生成」を押すと、選んだ方言の書式でCREATE TABLE文が出力されます。
  • 「SQL Builderで開く」を押すと、生成したDDLをそのままVisual SQL Builderに引き継いでクエリ作成に進めます。

FAQ: よくある質問

  • MySQL / PostgreSQL / SQLiteで型はどのように変わりますか?

    内部的には共通の論理型(INTEGER・DECIMAL・VARCHARなど)でテーブルを管理し、DDLを生成するタイミングでのみ各データベースの実際の型に変換します。例えばBOOLEANはSQLiteに真偽値型が無いためINTEGERに変換され、自動採番の主キーもMySQLはAUTO_INCREMENT、PostgreSQLはSERIAL、SQLiteはINTEGER PRIMARY KEY AUTOINCREMENTと、それぞれの流儀に合わせて出力されます。
  • PKにチェックを入れると、NOT NULL・UNIQUE・デフォルト値の指定はどうなりますか?

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

    トップレベルのプロパティがオブジェクトの配列の場合は、親テーブルへの外部キーを持つ別テーブルとして自動的に切り出されます(例: 注文と明細行)。ネストした単純なオブジェクトはJSON型のカラムとして扱われます。2階層より深いネストは自動でテーブル分割されないため、必要に応じて手動で調整してください。
  • 生成したDDLをそのまま本番のマイグレーションに使ってよいですか?

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

使いどころ: 主な活用シーン

  • 新しいAPI・サービスの初期テーブル設計

    新規開発の初期段階で、必要なテーブルとカラムをビジュアルに組み立て、そのままCREATE TABLE文として書き出せます。

  • 既存のJSONレスポンスからDBスキーマを逆算

    APIレスポンスやログのJSONサンプルを貼り付けて、対応するテーブル構成とDDLをたたき台として自動生成できます。

  • チームでのER図レビュー資料作成

    設計したテーブル構成をMermaid形式のER図としてその場で確認・共有でき、レビュー時の認識合わせに使えます。

  • sql-to-er / SQL Builderと組み合わせた設計フロー

    生成したDDLをSQL Builderに引き継いでクエリを組み立てたり、後日sql-to-erに貼り付けて構成を再確認したりと、設計からクエリ作成までの一連の流れをブラウザ内だけで完結できます。

注意点: 注意事項・制限

  • 生成されるDDLは基本的な制約のみです

    PRIMARY KEY・NOT NULL・UNIQUE・DEFAULT・FOREIGN KEYには対応していますが、インデックス、CHECK制約、文字コード・照合順序、パーティショニングなどは生成されません。本番のマイグレーションに使う前に必ず内容を確認してください。

  • JSONからの型推論はサンプルの内容に依存します

    与えたサンプルに含まれる値からしか型を推測できません。実際には他の型の値も入りうる場合は、生成後に型を手動で調整してください。

  • テーブル名・カラム名は予約語チェックをしていません

    各データベースの予約語(order、group など)と同名のテーブル・カラムを作成しても警告は出ません。生成したDDLがエラーになる場合は名前の重複を確認してください。

JSONから自動生成(任意)

テーブル設計

リレーション(外部キー)

DDL出力

ER図プレビュー

おすすめリソース

このセクションにはアフィリエイトリンクが含まれる場合があります。リンク経由で購入すると、追加費用なしでDevToolKits.appが紹介料を受け取ることがあります。

このツールの関連記事

最新記事

活用事例
2026-08-07

curlコマンドのオプション早見表|-X -H -d の意味と落とし穴

curlの主要オプションを早見表で整理。-X と -d の関係、-d と --data-raw の違い、@ で始まる値がファイル読み込みになる罠、シングルクォートとダブルクォートの使い分け、-L や -k を安易に付けない理由まで実例で解説します。

ツール紹介
2026-08-06

JSON SchemaとZodを相互変換する仕組み|requiredと.optional()の対応

JSON SchemaからZodスキーマを生成し、Zodのコードから逆にJSON Schemaを書き出す双方向変換ツールの実装を解説。requiredと.optional()で既定値が逆転している問題、formatや制約の対応表、コードを実行せずに解析する方法まで整理します。

活用事例
2026-08-06

SQLの句の評価順リファレンス|WHEREでSELECTの別名が使えない理由

SQLは書いた順に実行されません。論理的な評価順(FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY→LIMIT)を軸に、別名がWHEREで使えない理由、WHEREとHAVINGの使い分け、ONLY_FULL_GROUP_BY、COUNT(*)とCOUNT(列)の差、LEFT JOIN+WHEREの罠を実例で整理します。

活用事例
2026-08-06

unified diff形式の読み方リファレンス|@@ の数字とgit diffの出力

git diffが出力するunified diff形式の読み方を整理。@@ -12,7 +12,9 @@ の4つの数字の意味、コンテキスト行、空白だけの変更が行全体の置換に見える理由、\ No newline at end of file、マージ時の @@@、リネーム検出の similarity index までを実例で解説します。

活用事例
2026-08-06

UTC⇄JST変換リファレンス|時差9時間の早見表とタイムゾーン事故の防ぎ方

UTCとJSTの変換を早見表で整理。ISO 8601のZと+09:00の意味、JavaScriptの日付パースでズレる条件、MySQL/PostgreSQLのタイムゾーン挙動、GitHub ActionsのcronがUTCで動く罠まで実例付きで解説します。

活用事例
2026-08-04

CREATE TABLE リファレンス|MySQL・PostgreSQL・SQLiteの型と制約の違い

CREATE TABLE文(DDL)の書き方を3データベース横断の早見表で整理。型対応表、自動採番(AUTO_INCREMENT / IDENTITY / rowid)の方言差、外部キーのON DELETE挙動、CHECK制約が無視される罠まで実例付きで解説します。

広告

広告