【DB設計】見習いエンジニアが現場で学んだ「後悔しない」ための設計原則まとめ
データベースエンジニアの見習いとして現場に入り、先輩方の設計やトラブル対応を間近で見ていると、**「最初の設計の良し悪しが、数年後の開発効率やシステム移行（モダナイズ）の成否を決定づける」**ということを痛感します。 今回は、私が実務と学習を通じて学んだ、将来の自分（とチーム）を助けるための設計のコツを整理してまとめます。 1. NULLは「なるべく避ける」が鉄則 設計の初期段階で最も意識しているのが、「安易にNULLを許可しない」ことです。 プログラムを複雑にしない : アプリ側で値を取り出す際、常に「もしNULLだったら」というチェックが必要になり、バグの温床になります。 集計ミスを防ぐ : SQLの集計関数（ COUNT や AVG など）ではNULLが無視されるため、直感に反する計算結果を生むことがあります。 【現場での学び】 可能な限り NOT NULL 制約をつけ、未入力が想定される場合は「デフォルト値」を設定する。制約によってデータの品質をDBの入り口で担保する重要性を実感しています。 2. データベースの「制約」を最大限に活用する データの正しさを守るのはプログラムだけではありません。DB自体が持つガード機能を信頼することが大切です。 主キー（Primary Key） : データの重複を物理的に許さない。 一意制約（Unique） : 重複を避けるべき項目（メールアドレスなど）を守る。 チェック制約（Check） : 「0以上の数値しか認めない」など、値の妥当性をDBレベルで保証する。 アプリ側だけでなく、DB側で「守りの設計」を固めることで、直接データを操作した際のリスクも最小限に抑えられます。 3. 「有意コード」の誘惑に負けない 「商品コードの先頭2桁がカテゴリを表す」といった、値自体に意味を持たせた「有意コード」は、一見便利ですが避けるべきだと学びました。 仕様変更に弱い : カテゴリ体系が変わった瞬間、全てのコードを書き換える地獄が発生します。 無意コード（サロゲートキー）の推奨 : 意味を持たない連番などを主キーにし、属性（カテゴリなど）は別カラムで管理するほうが、将来の拡張やモダナイズに強い設計になります。 4. 「物理削除」ではなく「論理削除」を検討する データを消す際、 DELETE で消し去る（物理削除）のか、フラグで非表示に...