こんにちは。

"katayose" <katayose@xxxxxxxxxx>さんの
<007101c3f913$245745e0$937ba8c0@katayose>
"[mysql 08855] Re: "


> 初めまして、今月メンバーに参加しました。片寄と申します。
> 
> 問題を整理してみました。
> この整理が近藤のものと合致しているかわかりませんが、こう仮定したらということ
> で
> 解決策を考えてみました。
<snip>

　片寄さんの解決方針は、(3)で時間毎(24発)、送信と受信(２発)で合計48発の
クエリを発行する事になります(正確には(2)のテーブル削除とテーブル作成のク
エリ、結果を得るクエリの合計３発を含め51発ですが)。これはボクが[mysql
08847]の「しかし、 24*2=48発のクエリを出して、は少々問題があるでしょう」
と述べたやり方ですね。

　もちろん、この方法で目的を果たす事は可能なのです。しかし「少々問題があ
るでしょう」の通り、あまり良い方法とは言えません。mail_tb(とmaster_tb)が
どれだけのレコードを持っているのか定かではありませんが、数が多い場合には
DBMSに多大な負担を掛ける事になります。mail_tbが１万のレコードを持ってい
るとすれば、合計 48万レコードを (インデックスが張ってあれば48万のインデッ
クスを)舐める事になります。

　と言う事で、「TRANSFORM文が使えないのであれば、この様な処理はDBMSを使
っている処理系に任せてしまった方が好結果を生む」が[mysql 08847]の趣旨で
すし、その後のもりきゅうさんの[mysql 08849]、[mysql 08852]での解法でしょ
う。


　また別の解法としては、集計結果そのままのテーブルをあらかじめ作成して置
き、 mail_tbにレコードを追加する際に、その集計結果テーブルを更新する、が
あります。この時点では、日付、時間、送信者と受信者（とその所属グループ)
は確定している訳ですから、行追加クエリ(挿入失敗は無視)と送受信カウントの
更新クエリの単純な２発を余計に出すだけです。

　利点は処理が時間的に分散される、集計結果を得るのに集計結果テーブルへの
軽いクエリ１発で済む、です。他方難点としては、何らかの原因で集計結果に誤
りがあった場合には集計結果テーブルの再作成が必要で、その用意が工数的に不
利となるだろう、があります。


# [mysql 08847]での「[mysql08841]で沼田さんが示された方法位しか無いです
# ね」は、少々勘違いでした。反省。




　　　　松枝知直　　　　<tomom@xxxxxxxxxx>
　　　　　　　　　　　　http://www.argus.ne.jp/~tomom/