オンライン・データベース設計：ER 図・方言変換・構造チェック

機能

• テーブル関連図：テーブル名・列名・型・PK / FK の印・外部キーの線
• 3 方言の DDL：MySQL / PostgreSQL / SQLite
• 型の変換：AUTO_INCREMENT → SERIAL、DATETIME → TIMESTAMP、TINYINT(1) → BOOLEAN など
• 生成した DDL は依存順（参照されるテーブルが先）なので、まとめて実行できます
• 構造チェック：外部キーの参照先、索引の欠落、主キー、列名重複、予約語、型の書き方、ON DELETE
• 指摘は「エラー / 警告 / 参考」に分け、対象の名前を必ず添えます
• 変換の注記：失われる意味を 1 件ずつ表示（黙って処理しません）
• 解析できなかった行は報告します（黙って捨てません）
• 引用符は必要なときだけ付けます（予約語や特殊文字を含む場合）
• Ctrl / Cmd + Enter で分析。サンプルを最初から入れてあります

使い方

1. 左の欄に DDL を貼る（そのままサンプルでも可）
2. 対象の方言を選ぶ：MySQL / PostgreSQL / SQLite
3. 「分析」を押す（Ctrl / Cmd + Enter でも可）
4. 左に関連図、右にテーブル一覧・チェック結果・生成した DDL が出ます
5. 行ごとのコピーボタンで生成した DDL を取り出せます

よくある質問

どの SQL に対応していますか？

`CREATE TABLE`（列定義・列レベルと表レベルの主キー・UNIQUE・索引・外部キー・CHECK）と `ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY` のみです。ビュー・トリガー・ストアドプロシージャ・生成列・複雑な `DEFAULT` は解析せず、「この行は解析できませんでした」と警告します。推測するより、出さないほうがましだからです。

PostgreSQL で外部キー列の索引を指摘するのはなぜですか？

PostgreSQL は外部キーの参照列に自動で索引を作らないのに対し、MySQL（InnoDB）は作るからです。索引がないと、結合や親行の削除が走査に落ちます。対象方言ごとの指摘なので、MySQL を選ぶと出ません。

型の変換は信用できますか？何が失われますか？

対応表は短く明示的で（よくある型 20 種類ほど）、出力と突き合わせて確認できます。意味が失われる変換には必ず注記を付けます：`unsigned` は PostgreSQL に対応がなく（範囲が変わります）、`ENUM` は TEXT に退化し（値の制約が失われます）、`ON UPDATE CURRENT_TIMESTAMP` は移行先ではトリガーが必要です。表にない型はそのまま残して警告します。

生成した SQL はそのまま実行できますか？

できます。しかも依存順（参照されるテーブルが先）なので、まとめて実行しても存在しないテーブルへの外部キーで失敗しません。ただし 2 点：SQLite は外部キーが既定で無効なので、接続ごとに `PRAGMA foreign_keys = ON` が必要です（生成 SQL にもその旨を書いています）。またデータ移行のロジックは生成しません —— 既存データの移し方はお任せします。

逆はできますか（データベースから DDL を出す）？

できません。このサイトにはデータベースに接続するサーバーがありません。ただし `mysqldump --no-data`、`pg_dump --schema-only`、`sqlite3 .schema` で DDL を書き出して貼り付けられます —— それがこの道具の一般的な使い方です。