データベースの物理設計
アーキテクチャ設計を行う時にいろいろな方針を決めるようにしているのですが、データベースについても論理から物理に変換する基準を決定します。
僕らのチームではアプリケーションごとに以下の点について考えます。
- 非正規化をおこなってもよい基準
- 可変長文字列と固定長文字列の使い分け基準
- Date型やTimestamp型の利用基準
- カラムのNULL許可の基準
- サブタイプやフラグ（状態）の実装基準
- トリガーやVIEW、FK制約などのDBMS機能の利用基準
- ストアドプロシージャの利用基準
- 代理キーを利用する基準
最初の非正規化については、導出項目を除くと、基本的には検索時のJOINコストがボトルネックになるような場合のみ許容しています。
可変長・固定長はほとんど大きめにとって可変長にすることが多いのですが、キーやパフォーマンスが求められるテーブルでは固定長を検討します。
Date型については時分を含まない場合、文字列で代用するかどうか判断します。文字列で代用するとNULL値を空文字で表現できて便利なんですよね。
基本的にはNULL許可はしない方針なのですが、数値で０でNULL値扱いできないカラムについては検討します。
サブタイプは、共通カラムを親テーブルまたはサブタイプごとに保存するか、サブタイプを１つのテーブルに展開するかどうかを考えます。フラグは、フラグをカラムとして実装するか、PKのみのフラグ用のテーブルを用意して実装するかを考えます。フラグの値の分布が偏っている場合に強力な検索キーとして利用できます。
DBMS機能では、やはり、FK制約・カスケード機能などを中心に利用について考えます。ストアドについては、昔は利用することが多かったのですが、ORMを利用するようになって使わなくなってきました。ただ、バッチ処理などのデータ指向でパフォーマンスが必要な処理はストアドを考えます。
代理キーについては利用の有無や利用する場合の基準を考えます。代理キーは長い複合キーの集約を目的に利用するのことが多いのですが、ORMの利用やりレーションの単純化を目的にシステム内部のキー（レコードID)的な利用も考えます。*1
*1:追加
