« 個別案件にオブジェクト指向は要らない | トップページ | さようなら「画面ファイル」 »

2010.11.08

スタンプ属性や更新履歴テーブルの無駄っぽさ

 データベース設計の際に「スタンプ属性」を載せることが設計標準とされているプロジェクトは多い。典型的なところでは、

・レコード追加日時
・レコード追加ユーザID
・レコード追加プログラムID
・レコード最終更新日時
・レコード最終更新ユーザID
・レコード最終更新プログラムID

といった項目をテーブル毎に載せ、更新系の処理が起こるたびにアプリに更新させる。捺印するように設定されるので「スタンプ属性」と呼ばれる。私も何も疑問を持たずに昔から従っていたものだ。

 スタンプ属性の意義として、何か異状が生じた場合にそれらの値を調べることによって原因を特定しやすくなる、と説明される。しかし私のこれまでの開発経験の中で、そのように役に立った記憶が一度もない。

 今やスタンプ属性は、「要らないもの」ではないにせよ「とりあえず載せるもの」ではなくなっている。それは「必要であれば載せ、必要でないなら載せなくていいもの」である。

 なぜか。現在の実行環境では、DBMSやフレームワークのレベルでテーブル操作ログが取られていることがふつうだからだ。その内容を個々レコードのキー値で検索すれば、それがどんな処理によって追加され、更新され、削除されたかを、項目の値とともに一覧できる。スタンプ属性ではたかだか「追加」と「最終更新」あたりの記録しかできないのと対照的だ。

 同じ理由から、「更新履歴テーブル」も「必要であれば設け、必要でないなら設けなくていいもの」である。

 拙書『上流工程入門』でもアンチパターンとして説明したが、更新履歴テーブルに固執したDB設計に鉢合うことがある。テーブル毎にいちいち更新履歴を明細テーブルとしてぶら下げたり、区分を使って当該テーブル上に更新前データを保持できるようにするといった設計パターンだ。なぜそのようにするのかと問うと「わが社のシステムの伝統なんです」とか「昔からこのようにやってきて、今までとくに問題は起こっていません」という答が帰ってきたりする。「オブジェクト指向で設計したから」と説明されて椅子からころげ落ちそうになったこともある。

 たしかに、ある種のマスター項目や契約情報等については、どのように値が変更されたかをアプリレベルで管理する必要がある。しかしそのような項目はそれほど多くないし、それらの中でも別のやり方で対処できることも少なくない。必要が生じたときにログからチェックできればじゅうぶんなケースもあるし、スナップショット属性としてトランザクション側に記録しておけばいいこともある。なによりも、滅多に役に立たない要素を抱え込むことが許されるほどシステムの記述は単純ではない。ようするに「更新履歴テーブル」は「必要であれば設け、必要でないなら設けなくていいもの」である。

 思うに「スタンプ属性」や「履歴テーブル」は、テーブル操作のロギングが簡単ではなかった時代に求められたプラクティスだったのではなかろうか。そういう習慣を無批判に踏襲することで生じる問題は、いかにも認識されにくそうだ。その仕様が長年役立つことがなかったとしても「今までとくに問題は起こっていません」と思えてしまうかもしれない。

 必要ならそうする。必要でないならそうしない――言葉で言うのは簡単だが、開発実務でこれを励行するのは簡単ではない。原理的・抜本的に考えることが要求されるからだ。しかしときどきはこれをやらないと、開発スキルの中で無駄な知見が増えてゆく。それは「経験を積み重ねることで身についた知恵」ではなく「更新を怠ることで身についた贅肉」みたいなものだ。

|

« 個別案件にオブジェクト指向は要らない | トップページ | さようなら「画面ファイル」 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/49968633

この記事へのトラックバック一覧です: スタンプ属性や更新履歴テーブルの無駄っぽさ:

« 個別案件にオブジェクト指向は要らない | トップページ | さようなら「画面ファイル」 »