ヘッダ部と明細部が分かれている場合のデータセットについて
http://blogs.wankuma.com/yaju/archive/2007/10/17/102455.aspx
データセットかぁ…
http://blogs.wankuma.com/shannon/archive/2007/10/17/102495.aspx
複数明細の存在する伝票項目を正規化するとHeader項目とDetail項目に分かれます。
重複して保持するのは冗長だしトラフィックの無駄になります.......ここまでは理解を得られます。
ビジネスアプリの最終形は帳票だと認識している人が少なからず存在します。最近の帳票ツールはHeader/Detailを別々に指定することもでき、複雑な処理も代行してもらえます。
とはいうものの制約が付いたりするので、言語でDocumentViewを使って出力することも在ります。
その際、出力部分のコーディングの部分だけ見れば、入力DataSetは1つの方が楽である。バグりにくい。という理由で、Header/Detail混在の非正規型Tableで設計したりしてました。
ここまでは良いのですが、この非正規型テーブルの作成をどこが受け持つかという認識が大事だと思うのです。
select * from Header H join Detail M ON H.ID = M.ID
where 年月=当月
この文で印刷に必要なデータをすべて取得して、後段に回すのを見かけます。
データ量が少ない間は問題が無いのかもしれませんが大量の時は問題だと思うのだが。
確かにコーディングは楽でしょうが楽ならいいの? このスタイルの癖が身に付いた人はこれが当たり前になるようです。
間の工程で、Headerを読んだ時点で明細を取得し、コードで非正規化処理して後段に渡したいものです。
記事の中にでてくる画面系での展開も根は同じだと思います。扱いやすいという理由でそのようにコーディングしたものと思われます。
コーディング雛形がそのようになっていて何も考えずに踏襲している場合もあるなぁ。
非正規化の上記のSQLをViewとして登録してあり、それを利用せよとしている標準規約が現存したりします。
そもそも、ビジネスアプリの最終形は帳票なの? その視点でDB設計するから歪になるのじゃないの? 考えないSE/PGなんて要らない。