黒龍's Blog

てへっ。
実務上はどちらも正解だし、速度比較は、使用状態により左右されるので、1元的には語れない。その通りなんですが...orz。
追求して初めて知る事実もあり、面白い試行でした。

でも、最終帳票の書式に合わせて横持ちDB設計するのは、引っかかります。
書式は恒久的な保証はないので、書式が変わるとDB項目とずれて、処理が複雑化するのが嫌ですね。

> でも、最終帳票の書式に合わせて横持ちDB設計するのは、引っかかります。
ここは当然そうだと思います。帳票出力の頻度を考えてもパフォーマンス云々を言うのはずれてますしおっしゃるように変更された場合の影響もありますので。

　Pasie.といいます。ここでは初めまして。
　上記で気になったことがあり、Ognacさんのところで話させてもらっていたこともあり、ということで失礼ながら乱入させてもらいます。^^;

>ナンセンスだと思います。
　ナンセンスと仰られる理由がわからない。
　また、どのような比較であればナンセンスではないと考えておられるのでしょう?

>どちらも横持ちにすべき
　どういった理由ででしょう?
　積極的に横もちにすべき理由などないと私などはおもいます。

>逆に更新ばかりがあるようなら縦にしなきゃ同時実行制御にあたりまくってどうしようもなさそうに思います。
　そうですか?
　トランザクションの単位が12ヶ月分なら結局は変わりないと思います。

>速度差縮めるための縦横変換
　Ognacさんの視点はどうであったかはわかりませんが、縦横変換は表示の都合の話なだけなので、速度差を縮めるという意図はないのではないかと。
　また、パフォーマンスについては、私は教科書どおりに実装すればそれなりの速度がでるということが実証できた点で有意義だったとおもってます。(特に当初横もちで速いとされていた実装よりも、最終形の縦もちの実装のほうが速かったところに注目してほしい)

>バランスというか要件に応じたものをモデリング
　きつい言い方になりますが、相応の事情がない限り、教科書からはずれるような設計は可能な限りすべきではないと思います。誤解を恐れずに言えば、こういう発言は多くの場合、保身(実装してしまったコードとかの正当化)に使われることがおおいので、この手の発言が出たら要注意だと考える自分がいたりします。

黒龍です、
>>ナンセンスだと思います。
>　ナンセンスと仰られる理由がわからない。
>　また、どのような比較であればナンセンスではないと考えておられるのでしょう?

>>どちらも横持ちにすべき
>　どういった理由ででしょう?
>　積極的に横もちにすべき理由などないと私などはおもいます。

>>逆に更新ばかりがあるようなら縦にしなきゃ同時実行制御にあた>りまくってどうしようもなさそうに思います。
>　そうですか?
>　トランザクションの単位が12ヶ月分なら結局は変わりないと思います。

横持ちの理由ですが集計値っぽいテーブルなのでトランザクション単位が長いことエンティティとして１～12月の予実は必ず存在すること、利用局面でも1～12月はセットで扱うこと、通年の集計処理などが想像できることなどから横持ちすべきと書きました。

更新ばかりがあるようならというのは実績入力などのように同一月に対してN件ぶら下げるかたちで全くない月もあるケースを想定してました。言葉足らずですみません。
同時実行云々は更新機会が長くとも登録時期というのはだいたいかぶることが多いので注意は必要ってことです。そもそもそういったケースではエンティティを分けるべきなのですがどうも一連の流れからは一つのエンティティで折り合いをつける想定に思えたので。最終的な形で登録縦持ち、閲覧用に横持ちをバッチで作成なんかが実用的な落とし所かと。

縦横変換は表示のみの話じゃありませんよ。集計処理なんかはざらにありますしかなりの件数になることも多々あります。

要件やデータを正しくモデリングすることこそ教科書的だと思っています。おそらくそもそもの誤解がここにあるんでしょうけど１～12月という予実データを縦持ちにするのは正規かじゃないよってことです。

私のほうこそ乱入だったので申し訳ないです。

> １～12月という予実データを縦持ちにするのは正規化じゃないよってことで
　了解です。よくわかりました。(つもり^^;)

　私はあくまで命題に沿って、横持ち=正規化前/縦持ち=正規化後、という前提(つまりここに疑問は挟まない前提)で話をしてました。その上で、パフォーマンスを言い訳とした非正規化はどうか?というのが私の立場でした。
　しかし、モデリングという意味だと、視点によってデータ構造は変わりますよね。それは仰るとおりだと思います。たぶん私が、マスタデータとしての予実テーブルを設計したら、精密な状況はわかりませんが今回のケースだと、12行で予定列/実績列をつくったんじゃないかと思います。本文では「原価項目が加わったとき」などを想定されていたりしますが、そういう追加の可能性が高いのであればともかく、そうでなければそのようなことに備えるのは冗長だと思いますし、予/実も混成しての集計( select sum(額) from ~ )なんてほぼありえないわけなので、ここを1列にしているのは個人的には疑問ではありました。

　やっぱりモデリングって難しいですよね。　#まとまらないので無理やり締める--;
　今度モデリングについてognacさんにまとめてまらいましょう　#そして勝手に振る ^^;

匿名なのに、私には誰だか分かる・・・(^_^;)ありがとう。。。