ER 図は全列載せる — 共通カラムは非表示機能で隠す
列を省くと FK・NOT NULL の設計根拠が失われる。全列を残し、表示側で隠す。
「主要属性だけ」方針の欠点
「ER 図には PK / FK / 主要属性だけ書き、残りは DDL を見ろ」——これは簡潔に見えますが、実運用では図を単体で読む場面（レビュー資料・納品物・オンボーディング）で必要情報が落ちます。
- FK が見えない: 「主要」に FK が含まれるとは限らず、線だけ引かれて根拠列が不明になる
- NOT NULL / NULL 可否が読めない: 論理制約が図から消え、設計議論で根拠を示せない
- 監査列の有無が追えない: 論理削除
deleted_atの有無はレビューで必ず問われる - 列の追加削除で「図と DDL のどちらが正か」が揺らぐ: 省略ルールが曖昧だと、列追加のたびに「図に載せる列か否か」の議論が発生する
ER 図は「DDL の代わりに読める設計ドキュメント」として使えるのが理想です。そのためには全列を載せた方が良い——ただし共通カラムで箱が縦長になる問題は別の方法で解決します。
実例 — A5:SQL Mk-2 の「共通カラム非表示」でビフォー / アフター
A5:SQL Mk-2 では、全テーブルに共通で付く列（監査列・バージョン列・論理削除列など）を「共通カラム」として登録でき、ER 図表示時にそれらをまとめて非表示にできます。
| 状態 | 図に出る列 | ファイルに保存される列 | 用途 |
|---|---|---|---|
| 共通カラム 表示 | 全列（業務列 + 監査列） | 全列 | DDL 出力・実装者レビュー |
| 共通カラム 非表示 | 業務列のみ | 全列（変わらず） | 設計レビュー・業務担当説明・関係俯瞰 |
重要なのは「ファイル側には全列が残る」ことです。非表示は描画時のフィルタであり、列を削除しているわけではありません。そのためDDL 生成・整合チェック・後からの列検索にも影響しません。
典型的な共通カラム登録例: created_at / updated_at / created_by / updated_by / deleted_at / version。詳しくは 共通カラム設計 を参照。
設定手順の要点（A5:SQL Mk-2）
- 共通カラムを登録: ER 図の「設定」 → 「共通カラム」から、列名パターン（
created_at/updated_atなど）を追加。正規表現も可 - 表示切替: 「表示」メニュー → 「共通カラムを隠す／表示する」で ER 図全体を一括切替
- 個別エンティティの例外: 共通カラムを持たないテーブル（履歴テーブルなど）は自動で対象外。例外指定も可能
- 論理 ER / 物理 ER と組み合わせる: 「論理名のみ」「物理名のみ」の切替と併用できる（論理 vs 物理）
プロジェクト開始時に共通カラムを 1 回決めておくと、以後追加するテーブルにも自動で適用されます。設計ルールの一部として ER ファイルに埋め込むことで、チーム全員が同じ表示設定でレビューできます。
大規模スキーマはレイヤー分割で
共通カラム非表示で縦方向の重さは解決しますが、テーブル数が多すぎる問題は別です。100 テーブルを 1 枚に収めるのは無理で、関心領域（bounded context）で分割します。
- 全体俯瞰図: テーブル名と主な線のみ。20〜30 個以下に絞る
- ドメイン別詳細図: 「注文まわり」「在庫まわり」など 5〜10 個に絞って全列載せる（共通カラムは非表示）
- 論理 / 物理の切替: 1 ファイルで「論理名のみ」「物理名のみ」を切り替えて両方使う
A5:SQL Mk-2 は 1 つの DB から複数の ER 図ファイルを保持できます。「1 枚で全部」は諦める。ただし 1 枚あたりは全列載せるのが、設計情報を落とさない運用です。