📝

技術書読書ログ「達人に学ぶDB設計徹底指南書」

2024/04/08に公開

概要

設計はトレードオフ。DB設計の場合はデータの整合性とパフォーマンスがトレードオフになる。

方針としては、論理設計を物理設計よりも優先して、整合性を重視する。つまり、DB設計時は毎回、正規化をちゃんとやる。

というのもすぐに妥協に走らないようにするため。ハードウェアの性能向上によってパフォーマンスの問題も解消されていくことも予想されるので。

正規化は原則として第3正規形まで行い、関連も基本は"1対多"のみにする。

"多対多"の関連は関連実態を使って解消する。"1対1"は正規化の過程では作られない。

パフォーマンス目的の非正規化は最終手段にする。他に手段が無くなったときに、以下のリスクを確認したうえで行う。

代理キーは本来不要なキーで、他の開発者や後から見たときに役割が分かりにくいので、なるべく避ける。

オートナンバリングのキーはロックがボトルネックになることもある。

一意になるキーが使いまわされたり、途中でキーが刺す対象が変化する可能性があるケースでは、"タイムスタンプ"や"インターバル"が有効。

一意になるようなキーができない場合は、アプリケーションで整形したり、そもそもの仕様を調整することを検討する。

B-treeインデックスは、カーディナリティ(列の値の種類の多さ)が高い列ほど効果も高い。平均的に分散しているのがベスト。

5%に絞り込めるかどうかが1つの目安。

複合キーでは、先頭に近いほどカーディナリティが高くなるようにインデックスを定義する。

10年以上前の本にも関わらず、大部分が今でも使える知識。

RDBは枯れにくい、価値の高い技術だなといことを改めて思いました！

個人的な学び・気付きポイントは、意識が低かったところ。

業務でDB設計するときは、しばらくこれらのポイントを注意していこう！