スパゲッティ・
データベース
「とりあえずJSONで保存しよう」「カラム名はdata1, data2でいいや」。
設計をサボったツケは、必ず運用時に支払わされます。
データ整合性が崩れ、重複データが溢れ、修正パッチが新たなバグを生む。
それは「データ」ではなく、ただの「電子ゴミ」です。
- 1つのテーブルに100個以上のカラムが存在する（神テーブル）
- 「予備項目1」「予備項目2」という謎のカラムがある
- CSVやカンマ区切りの文字列が、そのまま1つのセルに入っている
- 外部キー制約を使っておらず、削除されたはずのユーザーの注文データが残っている
腐った土台の上に、頑丈な家（アプリケーション）は建ちません。
01. 正規化は礼儀である
「正規化（Normalization）」は、データを美しく保つための基本ルールです。
重複を排除し、矛盾が起きないようにテーブルを分割する。
パフォーマンスのためにあえて非正規化することもありますが、それは正規化を理解した上での「高等戦術」です。
何も考えずに1つのテーブルにすべて詰め込むのは、ただの「怠慢」です。
Data is forever.
02. 外部キー制約を恐れるな
「制約をつけると開発が面倒になる」というエンジニアがいます。
その通りです。それが仕事です。
データベースに不正なデータが入ることを防ぐ（防波堤になる）のが、DB設計者の責任です。
アプリケーション側のロジックだけで整合性を保とうとするのは、穴の空いたバケツで水を運ぶようなものです。
03. 命名はドキュメントだ
`flag_1`、`temp_data`、`status`（0, 1, 2, 9...）。
これらのカラム名を見て、中身を推測できますか？
`is_deleted`、`user_registration_step`、`payment_status` のように、
英語として読める名前をつけてください。
カラム名は、そのデータの一生を左右する「名付け親」としての責任を伴います。