履歴テーブルというもの

ちょっとソフトの検証を手伝うことになりまして。

自分のが検証されるのは嫌ですが、人のを検証するのは大好きです(性格悪)

ソフトの内容は、まあよく有る作業の計画をインプットしてその実績をとっていくというだけのものなので、一通り業務イメージと同じ手順で作業をしてみて、実際に履歴が取れているかを確認・・・うん、取れてるね。

で、念の為ソフトの画面からだけではなく、データベースの中も確認して…

……あれぇ……？

何故だ？履歴テーブルのフィールド数が、履歴画面に表示されているフィールド数より圧倒的に「少ない」

……これは嫌な予感。とりあえず他の検証結果を見る以前にプログラマに連絡。

僕「あのー、この履歴画面って、この履歴テーブルからどーやって作ってるんです？」
プ「ああ、履歴テーブルと計画データテーブルをJOINし……」
僕「おおおおおおおおおおい！！！」

プ「何か？」
僕「いや、じゃあ計画データ消したらどうなるの？」
プ「それはデータ不整合を起こすので、やらないで下さい」
僕「いや、でも仕組み上計画データは割とすぐ消すし、システム上も計画データを先に消すことはできるんですけど」
プ「それは運用でカバーしてください」

・・・・・・えーと

ちょっと自分の常識がおかしいのかどうかが分からなくなったので以下愚痴。

まずそもそも履歴とは何か。それは業務を行った結果、システムで言えばログであって、仕様として特別に許可された場合を除き改変されてはならない物だと思ってる。それはつまり、設計時点で他の作業や動作において極力影響を受けないように考慮するということで、そう考えると必然的に履歴テーブル一つで、履歴に関する全ての情報が網羅できるように作るのが一番安全なんじゃないかなぁと思ってる。(大きいシステムでは知らないけど)
それはつまり、履歴テーブルのあるフィールドが別のテーブルに依存する形をとらないようにするということで、ましてやJOINなんてそうそうするもんじゃないのではと思ってる。(履歴テーブルを履歴以外の目的で転用する場合は別ですが)

例えば、履歴に担当者を残したいと思ったら、やっぱり担当者コードと担当者名両方を履歴テーブル内に別個のフィールドで持つ方がデータ的には安全だと思う。担当者コードだけを持ち、逐一担当者マスタを参照して担当者名を表示させた方が、データ量的には少なくて済むのは分かるんだけど、例えばその社員コードという概念には臨時社員コードという意味も含んでおり、短期間に同一コードが使いまわされるケースもあるとしたらどうだろう。これは、ある時期には入社している筈の無い社員名がその時期の履歴画面に表示されてしまう。これは「履歴」としての価値を持たないデータだと思う・・・んだけどなぁ・・・。

要件定義として「こんなデータが履歴データとして表示されてほしい」というところまでは提示してあったみたいだけど、データベースの設計までは提示していない・・・ってか、そこの設計って一般的に言ってSEの仕事なのかしら、それともPGの仕事なのかしら・・・

まあ、PGは仕様通りにソフト作るのが第一だけど、自分がそもそも何をどのような目的で作っているのかを全く意識しなくていいってわけじゃないと思うんだけどなぁ・・・
てかこんな危険な設計で「運用でカバー」とかしれっと言わんで欲しいなぁ・・・ってこれって贅沢？