データベースエンジニアの見習いとして現場に入り、先輩方の設計やトラブル対応を間近で見ていると、**「最初の設計の良し悪しが、数年後の開発効率やシステム移行（モダナイズ）の成否を決定づける」**ということを痛感します。
今回は、私が実務と学習を通じて学んだ、将来の自分（とチーム）を助けるための設計のコツを整理してまとめます。
1. NULLは「なるべく避ける」が鉄則
設計の初期段階で最も意識しているのが、「安易にNULLを許可しない」ことです。
プログラムを複雑にしない: アプリ側で値を取り出す際、常に「もしNULLだったら」というチェックが必要になり、バグの温床になります。
集計ミスを防ぐ: SQLの集計関数（
COUNTやAVGなど）ではNULLが無視されるため、直感に反する計算結果を生むことがあります。
【現場での学び】
可能な限り NOT NULL 制約をつけ、未入力が想定される場合は「デフォルト値」を設定する。制約によってデータの品質をDBの入り口で担保する重要性を実感しています。
2. データベースの「制約」を最大限に活用する
データの正しさを守るのはプログラムだけではありません。DB自体が持つガード機能を信頼することが大切です。
主キー（Primary Key）: データの重複を物理的に許さない。
一意制約（Unique）: 重複を避けるべき項目（メールアドレスなど）を守る。
チェック制約（Check）: 「0以上の数値しか認めない」など、値の妥当性をDBレベルで保証する。
アプリ側だけでなく、DB側で「守りの設計」を固めることで、直接データを操作した際のリスクも最小限に抑えられます。
3. 「有意コード」の誘惑に負けない
「商品コードの先頭2桁がカテゴリを表す」といった、値自体に意味を持たせた「有意コード」は、一見便利ですが避けるべきだと学びました。
仕様変更に弱い: カテゴリ体系が変わった瞬間、全てのコードを書き換える地獄が発生します。
無意コード（サロゲートキー）の推奨: 意味を持たない連番などを主キーにし、属性（カテゴリなど）は別カラムで管理するほうが、将来の拡張やモダナイズに強い設計になります。
4. 「物理削除」ではなく「論理削除」を検討する
データを消す際、DELETEで消し去る（物理削除）のか、フラグで非表示にする（論理削除）のかの判断です。
論理削除のメリット: 「誰がいつ消したか」という履歴が残り、誤操作時もすぐに復旧できます。
使い分け: 監査ログが必要な重要データは論理削除、一時的なワークデータは物理削除など、データの性質で見極めることがプロの設計への第一歩です。
5. 日付・時刻データの「型」と「精度」にこだわる
日付データの扱いには、現場のノウハウが凝縮されています。
日付をCHAR型で格納するのはアリか？
現場で見かける CHAR(8)（'20231022'）などの文字列保持は、原則避けるべきだと考えています。
関数と整合性: 文字列だと「1ヶ月後の算出」などの日付関数が使えず、また「13月45日」のような不正データの混入も防げません。これが移行時の「クレンジング地獄」を招きます。
自動化の徹底
更新日時などはアプリ側でセットせず、DBのデフォルト機能（DEFAULT CURRENT_TIMESTAMP）に任せることで、記録漏れを防ぐのが鉄則です。
6. 「将来必要になるかも」という推測を捨てる（YAGNI原則）
「予備のカラムを作っておこう」「将来のために型を広くしておこう」といった**「かもしれない設計」**は不要です（YAGNI: You Ain't Gonna Need It）。
無駄なNULLの増殖: 使われないカラムはデータ品質を下げるだけです。
クリーンな移行: 「今」必要な最小限の構成で作り、必要になった時に正しく拡張する。これが最も移行（モダナイズ）しやすい設計です。
7. 「正規化」を崩すのは、最後の最後の手段
設計の基本は第3正規化まで行い、データの重複を徹底的に排除することです。
非正規化の代償: パフォーマンスのためにデータを冗長に持つ（非正規化）と、データの不整合リスクが常に付きまといます。
手順: インデックス調整やクエリ改善をやり尽くした後の「禁じ手」として初めて検討すべきだと学びました。
8. 明快な「命名規則」を徹底する
カラム名に一貫性を持たせる（例：更新日時は必ず updated_at）ことは、運用フェーズで絶大な効果を発揮します。開発者が迷う時間を減らし、システム全体の可読性を高めます。
まとめ：誠実な設計が「未来の自分」を助ける
設計に「正解」はありませんが、安易に楽な道を選ばず、論理的に説明できる設計を目指すことが大切です。一歩ずつ、移行しやすくバグの出にくい「美しい設計」ができるよう、これからも奮闘していきます。
0 件のコメント:
コメントを投稿