テーブル設計のレビューでは、DDLを読むだけだと関係性を見落としやすくなります。
CREATE TABLE が数個なら追えますが、10個を超えると外部キーのつながりを頭の中で保持するのが難しくなります。

SQL DDLからER図を作ると、テーブル同士の関係を先に俯瞰できます。

こんな場面で使う

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  user_id INTEGER NOT NULL,
  total INTEGER NOT NULL,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

SQL to ER図変換ツールに貼り付けると、テーブルと関連をMermaidのER図として確認できます。

erDiagram
  users ||--o{ orders : has

DDLを読むだけでは気づきにくい「どのテーブルが中心か」「依存が偏っていないか」を見やすくなります。

実例：中間テーブルを含む関係を見る

多対多の関係では、中間テーブルの役割が図に出るとレビューしやすくなります。

CREATE TABLE users (
  id INTEGER PRIMARY KEY
);

CREATE TABLE teams (
  id INTEGER PRIMARY KEY
);

CREATE TABLE team_members (
  user_id INTEGER NOT NULL,
  team_id INTEGER NOT NULL,
  role TEXT NOT NULL,
  FOREIGN KEY (user_id) REFERENCES users(id),
  FOREIGN KEY (team_id) REFERENCES teams(id)
);

このDDLからER図を見ると、team_members が単なる補助テーブルではなく、role を持つ重要な関連テーブルだと分かります。レビューでは、複合主キーやユニーク制約が必要か、同じユーザーが同じチームに重複登録されないかも確認します。

レビューで見るポイント

  • 外部キーが想定どおりの親テーブルを参照している
  • 中間テーブルの命名が分かりやすい
  • 1対多、多対多の関係が図で自然に読める
  • 不要に強い依存がない
  • 削除時の扱いを別途確認する必要がある

ER図はDDLの代わりではなく、レビューの入口です。
図で全体像をつかみ、細かい制約やインデックスはDDLで確認する流れが現実的です。

Mermaidとして残すメリット

生成したMermaidをREADMEや設計メモに貼ると、変更差分をテキストで追えます。
画像だけの構成図よりもレビューしやすく、Git管理にも向いています。

Mermaidとして残す場合は、図の粒度も決めておきます。ER図はテーブル関係、インフラ構成図はサービス間の通信、と役割を分けると1枚の図に詰め込みすぎずに済みます。

関連ツール