データベースの正規化？めんどくさいから全部一つのテーブルに突っ込んだ話
こんばんは！IT業界で働くアライグマです！
データベース設計において、「正規化」はよく議論されるトピックです。
第1正規形（1NF）、第2正規形（2NF）、第3正規形（3NF）……といった形でテーブルを分割し、データの冗長性を排除することが推奨されます。
しかし、開発の現場では、「そんなのめんどくさいから、全部1つのテーブルにまとめた方が楽じゃない？」という考えが浮かぶこともあります。
特に、短期間でプロトタイプを作る場合や、小規模なプロジェクトでは、「とにかく早く動くものを作る」 ことが優先されるため、正規化を省略する選択肢もあり得ます。
本記事では、正規化せずにすべてのデータを1つのテーブルにまとめたらどうなるのか？ という話を、実体験を交えながら解説していきます。
正規化とは何か？
正規化の基本
正規化とは、データの重複を減らし、整合性を保つためにテーブルを分割する設計手法のことです。
代表的な正規化のステップは、以下のようになります。
- 第1正規形（1NF）： 各カラムに単一の値を持たせる（リストや配列を入れない）
- 第2正規形（2NF）： 主キーに完全に依存しないデータを分割する
- 第3正規形（3NF）： 主キーに関係のないデータをさらに分割する
例えば、ECサイトのデータを正規化すると、通常はユーザー情報、注文履歴、商品情報などのテーブルに分割します。
しかし、「正規化って面倒くさい！」 という理由で、すべての情報を1つのテーブルにまとめた場合、どうなるでしょうか？
正規化しないとこうなる
1つのテーブルに全部詰め込んだデータ構造
例えば、次のような「注文履歴」テーブルを考えてみます。
| id | ユーザー名 | メールアドレス | 商品名 | 注文日 | 支払い方法 | 金額 | 住所 |
|---|---|---|---|---|---|---|---|
| 1 | 田中太郎 | tanaka@example.com | スマホ | 2024-03-01 | クレジットカード | 50000 | 東京都 |
| 2 | 田中太郎 | tanaka@example.com | イヤホン | 2024-03-02 | クレジットカード | 5000 | 東京都 |
この設計では、ユーザー情報（名前、メールアドレス、住所）が、注文ごとに何度も繰り返されることになります。
これは「非正規化テーブル」の典型的な例です。
あえて正規化しないメリット
クエリがシンプルになる
テーブルを分割しないことで、データ取得のクエリが簡単になります。
JOINを使わず、単純なSELECT文でデータを取得できます。
SELECT * FROM orders WHERE ユーザー名 = '田中太郎';
複雑なリレーションを意識せずにデータを扱えるため、開発スピードが向上します。
開発スピードが上がる
正規化を意識すると、テーブル設計に時間がかかることがあります。
しかし、1つのテーブルにまとめてしまえば、
- すぐにデータを登録できる
- 余計なテーブル設計を考えなくて済む
というメリットがあり、特にMVP（最小実用製品）を作る際には有効です。
柔軟にカラムを追加できる
テーブルを細かく分割していると、新しい要件が追加されたときに、複数のテーブルを修正しなければなりません。
しかし、1つのテーブルにまとめていれば、新しいデータ項目を追加するのが簡単です。
それでもデメリットが大きすぎる
データの冗長性が高くなる
例えば、ユーザーが10回注文すると、ユーザー名やメールアドレスが10回繰り返されます。
これにより、データベースの容量が無駄に増加します。
また、「田中太郎」がメールアドレスを変更した場合、すべてのレコードを更新しないと、一部の注文だけ古いメールアドレスが残るという問題が発生します。
UPDATE orders SET メールアドレス = 'tanaka_new@example.com' WHERE ユーザー名 = '田中太郎';
このように、更新の手間が増え、データの整合性を保つのが難しくなるのが大きなデメリットです。
データの一貫性が崩れやすい
1つのテーブルにすべての情報を詰め込むと、データの整合性が取りづらくなります。
例えば、ある商品が削除された場合、その商品に関連するすべての注文データも手動で修正しなければならない、という状況が生じます。
これは「整合性制約を適用しづらい」 という問題につながり、データの不整合が発生しやすくなります。
スケールしにくい
データが増えてくると、検索や更新のパフォーマンスが低下します。
正規化されていれば、ユーザー情報は1つのテーブルで管理され、変更が容易ですが、非正規化テーブルではすべてのレコードを更新しなければならないため、処理が遅くなります。
結局どうするべきか？
「正規化がめんどくさいから全部1つのテーブルにまとめる」という選択肢は、
- プロトタイプ開発
- 短期間で動くものを作りたい場合
などには有効ですが、本番環境では避けるべき設計です。
理想的なアプローチとしては、
- プロトタイプ開発の段階では、シンプルなテーブル設計を採用
- 本番環境に移行する前に、必要なレベルまで正規化する
という形が現実的です。
まとめ
データベースの正規化は、一見面倒ですが、長期的にはメリットが大きい手法です。
しかし、開発のフェーズによっては、あえて正規化を省略する判断もあり得ます。
- クエリのシンプルさや開発スピードを優先するなら、非正規化も選択肢の一つ
- データの整合性や保守性を重視するなら、適切に正規化すべき
- プロトタイプと本番環境で、設計を使い分けるのが賢い選択
「めんどくさいから1つのテーブルにまとめた」結果、大変なことになるケースも多いため、状況に応じて正規化を適用するバランス感覚が重要です！