設計要件 更新と検索のトレードオフ 

データベース設計要件として、物理要件と運用要件がある。
物理要件とは、データベースファイルの大きさ、更新ログファイルの大きさ、ファイルの成長性など。データの初期量や将来性を考えないといけない。
運用要件は、スループット、レスポンスタイム、バックアップ・リカバリなど。トランザクションの発生頻度やレスポンスタイムへの要求を考える。
これらは受託したような仕事で要求されることで、とても難しいことのように感じる。実際に僕の状態ではこの中で触れるような部分はほとんどない。この辺が分かるようにならないと、とてもDBエンジニアなんて名乗っちゃいけないのかなぁ。
データベースでの、更新処理と検索処理はトレードオフの関係になる。更新系を優先した設計にすると、検索に時間が負荷がかかるようになり、検索系を優先すると更新系の処理に負荷がかかる。システム的やテーブルごとに更新と検索のどっちが多いのかなどの業務処理のバランスを考えることが大事になる。以下にあげるのはその例。
正規化をすると、1つの事実が1箇所にしかないので、更新は1回で済むので楽。しかし、検索のためには結合する必要がでてくるのでアクセス負荷が増える。非正規化しておくと、1つの事実の更新に対して何箇所か更新しないといけない場合もでてくる。非正規化しておくと結合処理は必要ないので、検索には有効。
インデックスをつけると、検索ではインデックスを利用するのでアクセス効率が上昇する。しかし、更新ではデータと共にインデックスも追加・更新しないといけなくなるので、アクセス負荷が増大する。
導出データ項目(集計結果など)はつけると、検索系は楽になるが、更新系は大変になる。