本記事では『SQLアンチパターン』に登場する、論理設計フェーズにありがちな8つのアンチパターンをまとめます。
DB設計に携わる方にとって「やってしまいがちなミス」とその回避法を理解する助けになります。
第1章：Jaywalking（信号無視）
💥 アンチパターン概要
正規化を無視して、関連するデータを1つのテーブルに詰め込んでしまうパターン。
例：
注文と顧客情報を1つのテーブルに混在させる。
CREATE TABLE orders (
order_id INT,
customer_name VARCHAR,
customer_email VARCHAR,
...
);
🛠 回避策
各エンティティ（顧客・注文）ごとにテーブルを分け、リレーションで繋ぐ。
第2章：Naive Trees（素朴な木）
💥 アンチパターン概要
ツリー構造を表現するために、親IDを単純に同じテーブルに格納する。
CREATE TABLE categories (
id INT PRIMARY KEY,
name VARCHAR(100),
parent_id INT
);
✅ 問題点
- 再帰的なクエリが必要
- 深さ無制限のツリーが扱いにくい
🛠 回避策
階層構造の管理には「経路列挙モデル」「ネスト集合モデル」などの採用を検討。
第3章：ID Required（とりあえずID）
💥 アンチパターン概要
すべてのテーブルに無理やりID（主キー）を付与し、自然キーを無視する設計。
CREATE TABLE countries (
id INT PRIMARY KEY,
country_code CHAR(2),
country_name VARCHAR(100)
);
🛠 回避策
安定した自然キーが存在する場合は、それを主キーとして使うべき。
第4章：Keyless Entry（外部キー嫌い）
💥 アンチパターン概要
外部キー制約を設けず、アプリケーションで整合性を管理しようとする。
✅ 問題点
- データの整合性が保証されない
- 意図しない削除・更新で不整合発生のリスク
🛠 回避策
外部キー制約をDBで明示的に設定すること。整合性はDBの責任。
第5章：Entity-Attribute-Value（EAV）
💥 アンチパターン概要
柔軟性を求め、属性を縦持ちの形式で格納する。
CREATE TABLE attributes (
entity_id INT,
name VARCHAR(50),
value VARCHAR(255)
);
✅ 問題点
- 型制約が効かない
- 集計・検索が困難
- スキーマが不明確になる
🛠 回避策
正規化されたカラム設計を採用し、拡張性が必要な場合は別テーブルを検討。
第6章：Polymorphic Associations（ポリモーフィック関連）
💥 アンチパターン概要
1つのリレーションで複数のテーブルを参照できるようにする構造。
CREATE TABLE comments (
id INT PRIMARY KEY,
commentable_type VARCHAR(50),
commentable_id INT
);
✅ 問題点
- 外部キー制約が使えない
- リファレンス先が曖昧
- JOINや集計が煩雑
🛠 回避策
各対象ごとに別テーブルにする、または中間テーブルで接続する構造にする。
第7章：Multicolumn Attributes（複数列属性）
💥 アンチパターン概要
繰り返しデータを、複数のカラム（列）で表現してしまう。
CREATE TABLE users (
id INT,
phone1 VARCHAR,
phone2 VARCHAR,
phone3 VARCHAR
);
✅ 問題点
- カラム数が増える
- 柔軟性がなく、変更に弱い
🛠 回避策
繰り返しは別テーブルに切り出し、1対多のリレーションにする。
第8章：Metadata Tribbles（メタデータ大増殖）
💥 アンチパターン概要
メタデータを動的に増やせるように設計した結果、無秩序にデータ構造が肥大化する。
CREATE TABLE field_definitions (
field_id INT,
field_name VARCHAR,
field_type VARCHAR
);
CREATE TABLE field_values (
entity_id INT,
field_id INT,
value VARCHAR
);
✅ 問題点
- メタデータが管理不能
- 実行時型チェックなどが困難
- 可読性が極端に低い
🛠 回避策
静的スキーマをベースに、アプリケーションロジックで拡張を検討。
📘 おわりに
論理設計でのアンチパターンは、「柔軟性」や「将来の拡張性」を意識しすぎた結果、
かえってパフォーマンスや整合性、メンテナンス性を犠牲にするケースが多く見られます。
正規化・適切な制約・設計時の意図の明確化こそが、よいDB設計への第一歩です。