例として、売上伝票の鏡部分(ヘッダー部: 顧客名称等の欄)と商品明細(商品名と価格等の欄)を考えます。
(消費税が入るので、実際は子伝票に工夫がいりますが、省略します。)
【鏡部分】
得意先Code/名称 TOK001 : 亜衣上夫
住所/連絡先 大阪市南区杉下xxxxxx 06-xxxx-xxxx
購入代金(税抜き) 149,000
購入数量 4
明細行数 3
【明細部分】
行目 商品コード 名称 単価 個数
1 A001 厚型テレビ 120,000 1
2 D51 5級スーパーラジオ 3,000 2
3 C57 貴婦人パック 23,000 1
ありがちな、売上情報です。明細行数は 購入代金と購入数量は、明細のサマリーになります。
親レコードの構成として。
親伝票No, 得意先Code は必要です、
(*)名称 , 住所/連絡先 は得意先マスタ引用で足りるか否かで必要性が決まります。
売価と購入数量は明細部分の総和なので算出項目です。
子レコードの構成として。
親伝票No, 子行数, 商品コード、個数
(*)商品名称は、商品マスターの引用で足りるか否かで必要性が決まります。
ここまでは、定石の類です。
取り上げたかったのは、(上記の例で)明細行数(3),購入代金(149,000),購入数量(4)という情報を、親レコードとして保持するか否かです。
保持する設計になっているプロジェクトを時折見かけます。
私は、副問い合わせか outer left join で (select count(*) 行数 from xxxx....)をかませば充分だと、思うので冗長性を感じます。
「何か有ったとき、行数値と実行数が合わなくなったときの、チェックに必要だ」という意見で、親持ちにしているらしいのですが、なんか有った時点で、テープル整合性が崩れているわけで、親持ちの値を使って、なにか解るものではないような気がしています。
時間コストの節約というのも、説得力にかけそうですし。
使い道がイマイチ不明です。「伝統的にそうしてきた。」というのが実際のような気がします。
明細行の増減で、親行を更新するのは、必然性がなく。親行に対するIO部分のソースと処理工程が増える分、バグ埋没する可能姓が増えそうです。
マイナス要素の方が多いように思うのです。
そうやって眺めてみれば、算出項目を保持するために、プログラム開発量とテスト量が増えて、余計なコストを増やしている気がします。
確かに、明細量が多くて、算出項目に時間コストがかる場合は、効果がありますが、普通の売上伝票ならは、僅かなコストです。
その僅かなコストの節約に、開発工数を増やすのはトータル的にﾄﾞｳなのでしょうか。
全て計算項目で実装してみて、プロファイラー的な事を実施して、ネックがあれば、親持ちに移行を検討するのが良いと考えます
昔からの継続しているシステムならば、データ構造を変えるのは、リスクが伴うので避けるのは理解できます。
新規でも、伝統的な項目設計スタイルって根付いているようで、モデリングや正規化などの論理では打破できない文化があるようです。