はじまり
業務の中で1つのトランザクションデータを複数に分割されているテーブル構成があり、3階層セレクトというアーキテクチャがあるそうなので調べてみた。
結果
そのようなアーキテクチャはない…？
説明を受けたアーキテクチャ構成
受注テーブルがあったとして、テーブル名を受注としたとき、以下の3つのテーブルに分割する。
- 受注R
- 受注S
- 受注W
それぞれのアルファベットと意味は以下を表す。
| アルファベット | 英語表記 | 用途 |
|---|---|---|
| R | Real | 直近データの保持に使用 |
| S | Stock | ちょっと古いデータの保持に使用 |
| W | Warehouse | 古いデータの保持に使用 |
この構成をとることにより、直近データを全表走査しても高速に対象データを取り出すことができ、かつ古いデータを結果から省くことが出来る。
足を引っ張るだけのような…？
この構想には以下の問題があると考えます。
- 保持期間(直近、ちょっと古い、古い)の判断基準
- 保持期間の判断基準がデータの用途によって異なる
- 保持期間ごとにどのテーブルへのクエリなのかアプリケーション側で判断する必要性が増える
- 同様にバッチ処理などで保持期間ごとの適切なテーブルへのデータ移行の必要性が増える
かなり現実的ではないことだらけのような気がします。
解決策
日付などの基準でパーティションテーブルを使ったほうがいいと思います。
まさにパーティションテーブルの得意分野！という感じがします。
パーティショニングの運用は追加されますが、全表操作しても範囲を限定できますし、テーブルとしては1つになるので保持期間の概念の考慮がシンプルになります。
最後に
この説明を受けた際に「3階層セレクトアーキテクチャをご存知ないんですか？ｗ」と嘲笑されるように指摘され、結構カチンときました。
ですが、私がDB2を知らないだけで、これが常識かも知れません。
また、DB2のバージョンが古いためパーティションテーブルなどがなく、プロジェクトとしてこのようなアーキテクチャを設計し、採用したのかもしれません。
「常識」ってやつはほんとに厄介なやつです。