感想「SQLアンチパターン」

前置き

SQLアンチパターン を読了しました。

最近のプロジェクトでデータベース設計の重要性を痛感する場面が多く、「正しい設計とは何か」を学ぶためにこの本を手に取りました。

この書籍は25のアンチパターンを通じて、多くの開発者が陥りがちな設計上の罠を体系的に解説しています。読み進めるうちに「あ、これ以前やったことある...」と冷や汗をかく場面も多々ありました。

内容の一部は理解が追いつかない部分もありましたが、データベース設計における重要な原則を学ぶことができたので、特に印象に残った部分をここにまとめます。

誰向けの記事か

• データベース設計の基本を学び直したいエンジニア
• SQLの書き方で悩むことがある開発者
• 保守性の高いデータベース設計に興味がある方

特に学びとなったアンチパターン

1. ジェイウォーク（配列の格納）

問題

カンマ区切りで複数の値を一つのカラムに格納してしまうパターンです。

-- アンチパターンの例
CREATE TABLE Articles (
  id INTEGER PRIMARY KEY,
  title VARCHAR(100),
  tags VARCHAR(200)  -- 'tag1,tag2,tag3' のように格納
);

なぜ問題なのか

• 特定のタグを持つ記事を検索するのが困難
• データの整合性を保証できない
• 正規化の原則に反する

解決策

中間テーブルを使用した正規化された設計に変更する。

-- 正しい設計
CREATE TABLE Articles (
  id INTEGER PRIMARY KEY,
  title VARCHAR(100)
);

CREATE TABLE Tags (
  id INTEGER PRIMARY KEY,
  name VARCHAR(50)
);

CREATE TABLE ArticleTags (
  article_id INTEGER,
  tag_id INTEGER,
  PRIMARY KEY (article_id, tag_id),
  FOREIGN KEY (article_id) REFERENCES Articles(id),
  FOREIGN KEY (tag_id) REFERENCES Tags(id)
);

私も以前のプロジェクトで「とりあえず動けばいいや」という気持ちで、似たような設計をしてしまったことがあります。後々の機能追加で非常に苦労した経験があるため、この章は特に身に染みました。

2. フィア・オブ・ジ・アンノウン（NULL恐怖症）

問題

NULLを嫌うあまり、デフォルト値を不適切に設定してしまうパターンです。

-- アンチパターンの例
CREATE TABLE Users (
  id INTEGER PRIMARY KEY,
  name VARCHAR(50) NOT NULL DEFAULT '',
  birth_date DATE NOT NULL DEFAULT '1900-01-01',
  phone VARCHAR(20) NOT NULL DEFAULT '000-0000-0000'
);

なぜ問題なのか

• 「値が存在しない」という情報が失われる
• 無意味なデフォルト値により、データの意味が曖昧になる
• 条件分岐が複雑になる

解決策

NULLを適切に活用し、必要に応じてNOT NULL制約を設定する。

-- 改善された設計
CREATE TABLE Users (
  id INTEGER PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  birth_date DATE,  -- 不明な場合はNULL
  phone VARCHAR(20)  -- 未登録の場合はNULL
);

この部分を読んで、NULLに対する見方が大きく変わりました。NULLは「悪いもの」ではなく、「情報がない」という状態を適切に表現する重要な仕組みだと理解できました。

3. ラウンディングエラー（丸め誤差）

問題

通貨や精密な計算が必要な数値にFLOATやDOUBLE型を使用してしまうパターンです。

-- アンチパターンの例
CREATE TABLE Orders (
  id INTEGER PRIMARY KEY,
  amount FLOAT,  -- 金額を浮動小数点で格納
  tax_rate FLOAT
);

なぜ問題なのか

• 浮動小数点数は正確な値を表現できない場合がある
• 計算結果に誤差が蓄積される
• 金融システムでは致命的な問題となる

解決策

DECIMAL型やNUMERIC型を使用し、精度を明示的に指定する。

-- 改善された設計
CREATE TABLE Orders (
  id INTEGER PRIMARY KEY,
  amount DECIMAL(10,2),  -- 精度を明示
  tax_rate DECIMAL(5,4)
);

金額の計算でこの問題に遭遇したことがあります。「なぜか1円ずれる」という問題で数時間悩んだ経験があるため、この重要性は身に染みて理解できました。

4. アンビギュアスグループ（曖昧なグループ化）

問題

GROUP BYでグループ化した際に、集約関数を使わない列を SELECT に含めてしまうパターンです。

-- アンチパターンの例（MySQLの一部バージョンでは動作するが問題あり）
SELECT user_id, name, MAX(created_at)
FROM posts
GROUP BY user_id;

なぜ問題なのか

• nameはグループ化されていないため、どの値が返されるか不定
• データベースによって動作が異なる
• 意図した結果にならない可能性が高い

解決策

集約関数を適切に使用するか、ウィンドウ関数を活用する。

-- 改善されたクエリ
SELECT user_id, 
       name,
       created_at
FROM posts p1
WHERE created_at = (
  SELECT MAX(created_at) 
  FROM posts p2 
  WHERE p2.user_id = p1.user_id
);

-- またはウィンドウ関数を使用
SELECT user_id, name, created_at
FROM (
  SELECT user_id, name, created_at,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) as rn
  FROM posts
) ranked
WHERE rn = 1;

5. スパゲッティクエリ（複雑すぎるクエリ）

問題

一つのクエリで全てを解決しようとして、可読性や保守性を犠牲にしてしまうパターンです。

-- アンチパターンの例（読みにくい巨大なクエリ）
SELECT u.name, 
       COUNT(DISTINCT p.id) as post_count,
       AVG(CASE WHEN c.rating >= 4 THEN 1 ELSE 0 END) as good_rating_ratio,
       (SELECT COUNT(*) FROM followers f WHERE f.user_id = u.id) as follower_count
FROM users u
LEFT JOIN posts p ON u.id = p.user_id AND p.created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
LEFT JOIN comments c ON p.id = c.post_id
WHERE u.active = 1
GROUP BY u.id, u.name
HAVING post_count > 5
ORDER BY good_rating_ratio DESC, follower_count DESC;

解決策

CTEやビューを使用して、クエリを分割し可読性を向上させる。

-- 改善されたクエリ（CTE使用）
WITH recent_posts AS (
  SELECT user_id, id
  FROM posts
  WHERE created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
),
user_stats AS (
  SELECT u.id, u.name,
         COUNT(DISTINCT rp.id) as post_count
  FROM users u
  LEFT JOIN recent_posts rp ON u.id = rp.user_id
  WHERE u.active = 1
  GROUP BY u.id, u.name
  HAVING post_count > 5
)
SELECT * FROM user_stats
ORDER BY post_count DESC;

複雑なレポート機能を実装する際に、このようなスパゲッティクエリを書いてしまい、後でデバッグに苦労した経験があります。

6. リーダブルパスワード（平文パスワード）

問題

パスワードを平文で保存してしまうパターンです。

-- アンチパターンの例
CREATE TABLE Users (
  id INTEGER PRIMARY KEY,
  username VARCHAR(50),
  password VARCHAR(100)  -- 平文で保存
);

なぜ問題なのか

• セキュリティリスクが極めて高い
• データ漏洩時に甚大な被害をもたらす
• 法的な問題に発展する可能性

解決策

ハッシュ化（できればソルト付き）して保存する。

-- 改善された設計
CREATE TABLE Users (
  id INTEGER PRIMARY KEY,
  username VARCHAR(50),
  password_hash VARCHAR(255),  -- ハッシュ化された値
  salt VARCHAR(255)  -- ソルト値
);

パスワードのハッシュ化は暗号化とは異なります。ハッシュ化は一方向の処理で、元の値を復元できません。適切なハッシュアルゴリズム（bcrypt、Argon2等）を使用することが重要です。

7. SQLインジェクション

問題

ユーザー入力を直接SQLクエリに組み込んでしまうパターンです。

// アンチパターンの例（Node.js）
const userId = req.params.id;
const query = `SELECT * FROM users WHERE id = ${userId}`;
db.query(query);

なぜ問題なのか

• 悪意のある入力により、データベースが不正操作される
• データの漏洩、改ざん、削除のリスク
• アプリケーション全体のセキュリティが脅かされる

解決策

プリペアドステートメントやパラメータ化クエリを使用する。

// 改善されたコード
const userId = req.params.id;
const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [userId]);

セキュリティは後回しにしがちですが、開発の初期段階から意識することの重要性を改めて感じました。

8. マルチカラムアトリビュート（列の重複）

問題

関連するデータを複数の列で表現してしまうパターンです。

-- アンチパターンの例
CREATE TABLE Users (
  id INTEGER PRIMARY KEY,
  name VARCHAR(50),
  phone1 VARCHAR(20),
  phone2 VARCHAR(20),
  phone3 VARCHAR(20)
);

なぜ問題なのか

• 柔軟性がない（電話番号が4つ以上必要になった場合）
• NULLが多く発生する
• 検索クエリが複雑になる

解決策

正規化を行い、別テーブルで管理する。

-- 改善された設計
CREATE TABLE Users (
  id INTEGER PRIMARY KEY,
  name VARCHAR(50)
);

CREATE TABLE UserPhones (
  id INTEGER PRIMARY KEY,
  user_id INTEGER,
  phone_number VARCHAR(20),
  phone_type VARCHAR(20),  -- 'mobile', 'home', 'work' など
  FOREIGN KEY (user_id) REFERENCES Users(id)
);

実践で活かしたいポイント

1. 設計前の要件整理

アンチパターンの多くは、要件の曖昧さや将来の拡張性を考慮しないことから生まれています。

• どのような検索パターンが必要か
• データの更新頻度はどの程度か
• 将来的にどのような機能追加が予想されるか

これらを事前に整理することで、適切な設計選択ができるようになります。

2. パフォーマンスと保守性のバランス

正規化を進めすぎると複雑なJOINが必要になり、パフォーマンスが悪化する場合があります。逆に非正規化しすぎると、データの整合性維持が困難になります。

プロジェクトの特性に応じて、適切なバランスを見つけることが重要だと学びました。

3. インデックス戦略

多くのアンチパターンは、適切なインデックスの設定により回避できる場合があります。

• よく使用される検索条件に対するインデックス
• 複合インデックスの順序
• 不要なインデックスの削除

これらを意識してデータベース設計を行うことで、パフォーマンスの向上と保守性の両立が可能になります。

終わりに

SQLアンチパターンを読んで、データベース設計の奥深さを改めて感じました。

「動くコード」を書くだけでなく、「長期間にわたって保守可能で拡張性のあるコード」を書くことの重要性を再認識しました。特に、データベース設計の判断は後から変更するのが困難なため、最初の設計が非常に重要です。

ORMとの関係について

普段の開発では、TypeScriptであればTypeORM、LaravelならEloquent ORM など、直接SQLを書くことは少なくなりました。しかし、この本を読んで感じたのは、ORMの便利さに依存しても、根本的な設計原則を理解していることの重要性です。

ORMがアンチパターンをある程度サポートしていたとしても、それがベストプラクティスとは限りません。また、パフォーマンスの問題やORMでは表現しにくい複雑なクエリに遭遇した際に、SQLの知識が必要になります。

抽象化されたツールを使っているからこそ、その土台となる知識をしっかりと身に付けておくことが大切だと感じました。

AI開発時代のアンチパターン理解

最近、Claude Codeを使ってアプリケーションを開発することが多くなりました。AIは驚くほど優秀で、短時間で機能的なコードを生成してくれます。

しかし、AIが完璧ではないことも事実です。AIがアンチパターンを含むコードを生成してしまった場合、それを見抜いてレビューできるのは結局人間です。AIの生成したコードに対するセーフティネットとして、アンチパターンの知識が重要だと感じています。

これはSQLに限った話ではなく、設計パターン全般に言えることです。AIと協働する時代だからこそ、基礎知識がより一層重要になってくると思います。

本書で学んだアンチパターンを避けることで、より良いデータベース設計ができるようになると思います。ただし、すべてのアンチパターンを機械的に避けるのではなく、プロジェクトの要件や制約に応じて適切な判断を下すことが大切だと感じました。

今後のプロジェクトでは、この知識を活かしてチームメンバーと設計議論を行い、AIとも適切に協働しながら、より良いシステムを構築していきたいと思います。

データベース設計は一度学んだら終わりではなく、継続的な学習と実践が必要な分野です。引き続き学習を続けていきます。

参考

• SQLアンチパターン
• データベース設計のアンチパターンを学ぶ