トレードオフについてのお話

先日、ある機能のテーブル設計を任されました。

設計するに当たって、そういえばDBについてちゃんと勉強したことって、新卒で入った会社でORACLE MASTER BRONZEを取らされたときに勉強したくらい、しかもDBAとかとSQLに関する知識くらいでした。
DB・テーブル設計についてはWeb上の記事から得た知識が多く、体系だった知識って勉強したことがないことに気付きました。

いい機会なのでDB・テーブル設計についてちゃんと勉強したいなと思っているところで見つけた良さげな本がこちら。
DBに関する本を数多く出版されているミックさんの本です。なにやら評判がいいので読んでみました。

今回はその中でも「トレードオフ」に絞って取り上げてみます。

達人に学ぶDB設計 徹底指南書

フリーランチはない

意思決定に関する最初の原理は、「無料の昼食（フリーランチ）といったものはどこにもない」ということわざに言い尽くされている。自分の好きな何かを得るためには、たいてい別の何かを手放さなければならない。意思決定は、一つの目標と別の目標のトレードオフを必要とするのである。

マンキュー入門経済学からの引用です。(経済学部だったので懐かしい)
「「無料の昼食（フリーランチ）といったものはどこにもない」」というのはつまり「代償なしに何かを得ることはできない」という意味です。
DB設計においてよく取り上げられる2つの要素、論理設計と物理設計、これらもトレードオフの関係にあります。論理設計を綺麗にしようとすると物理設計が犠牲になり、その逆も然りです。どちらも完璧にすることは難しくバランスを考えながら設計する必要があります。

DB設計においてトレードオフの関係にあるものを以下に挙げました。

1. 正規化とパフォーマンス

テーブルはできるだけ高次の正規形に向けて正規化するのが原則と言われています。(実際は第3正規形くらいまで正規化すれば十分のようですが)
ただし正規化すればするほど検索時にテーブルを結合する必要がありパフォーマンスが低下します。
パフォーマンスを上げるにはインデックスを作成するなど方法がありますが、場合によっては正規化の逆、非正規化という手段という選択肢を取らざるを得ないことも。
テーブルを正規化してデータの整合性を保ちたいという思いとパフォーマンスを向上させたいという思いはまさにトレードオフの関係にあるということですね。

2. バックアップのリカバリコストとバックアップコスト

DBのバックアップにはいくつか種類があります。
1. フルバックアップ
2. 差分バックアップ
3. 増分バックアップ

1. フルバックアップは名前の通り全てのデータをバックアップする方式です。
従って最新のバックアップデータさえあればバックアップ時のデータを全て復旧させることができます。従ってリカバリコストは3つの中だと最も低いです。ただし全てのデータを世代数分保持するので多くのストレージ容量が必要になりバックアップコストは嵩みます。

一方3. 増分バックアップにおいてはバックアップデータはフルバックアップとその日以降に変更分のみバックアップされた増分バックアップのデータ全てのファイルが必要となります。更にリカバリに要する時間も長くなることからリカバリコストは3つの中では最も高くなります。ただしフルバックアップ以降に変更されたデータのみを増分バックアップとして保持するのでストレージの容量は少なくて済みます。

このようにリカバリコストを抑えるほうを選ぶか、バックアップコストを選ぶ方を選ぶか、これらには正解はなくあくまでそのチーム・プロジェクトにおいてのどちらをどの程度優先するかという決め事になります。

まとめ

システム開発だけでなく、私生活においても上記のようなトレードオフの関係にある事柄はよくありますが、やはり重要なのは「どちらを優先するか」意思決定を下すことです。
絶対的な正解があれば話は別なのですが多くの場合はそのようなものはなく、あくまでその組織で何が求められるのか、更にどのフェーズにいるかによって優先する項目が変わります。(アーリーステージでは質よりもスピードが求められるなど)

自分の組織が今どういう状況かを見極めて、その時にベストな判断を下せるように心がけましょう。

(サムネイル画像はこの間初めて食べた崎陽軒のシウマイ弁当)