鮎を食べるのは楽じゃない、その１～STAとMTAの話～
http://blogs.wankuma.com/esten/archive/2008/01/23/118945.aspx
鮎を食べるのは楽じゃない、その２～SELECT文をどう処理するか～
http://blogs.wankuma.com/esten/archive/2008/01/24/119106.aspx
の続き
「川から全部の鮎を取ってくる」仕事をこなす鵜飼のお話なんですが、前回で大量に出したサンプルのうち、本当に無駄なくきちんと「川から全部の鮎を取ってきた」鵜飼さんは半分もいなかったわけですが、その理由は以下のような問題を抱えてしまうからです。
サーバー上でのテーブルロック問題
データベースからレコード取得処理を行う場合、テーブルロック、つまり、レコード排他についてきちんと状況を理解して使用する必要があります。例えるなら、「一匹の鮎を捕まえようと複数の鮎がつかみあいをしてしまう」という状況は避ける必要がある、ということです。鵜は「取って来い」といわれた鮎を素直に探して取ってこようとします。不幸にもその鮎が他の鵜も取ろうとしている鮎だった場合にはどちらも譲らないのです。結果、とりあいへしあいにらみ合い、いつまで経ってもその鮎が取れるまで鵜は鵜匠の元には戻ってきません。１０羽の鵜が好き勝手に鮎の取り合いをしていては、ぶつかったり、紐が絡まってしまうこともあるでしょう。それらを避けるためにも、一羽一羽の鵜が確実に鮎を探し出せるように、鵜匠がきちんとコントロールする必要があるのです。
データ取得の論理的な問題
たとえば「この川にいる２００匹の鮎を取る」場合、鵜匠一人に鵜が一羽なら時間は掛かりますが確実に「川の中にいる２００匹の個体が異なる鮎」を取ってくる事ができます。つまり、取って来た鮎の一匹一匹のDNA検査をしても、確実に「２００匹の鮎」と言い切る事ができるのです。が、多くの鵜を放った場合、それぞれの鵜が取ってくる鮎が同じ鮎である可能性があります。（現実というかリアルな鵜飼では無いんですけど（大汗））厳密にいえば、複数の鵜を使う場合には「川にいる２００匹の鮎を取る」という曖昧な命令でなく「DNA鑑定して別個体であるとはっきり判る鮎を２００匹、分担して取って来い」という命令にしないと、取って来た２００匹の鮎が同じものばかり、実はクローンで作られた人造魚で食べられない鮎でした、なんていう、それなんてSF？なオチがまっている危険をはらみます。
なんて頭の痛いＳＦな問題だ（笑）、けれど、これらの問題はほんのちょっとの発想で回避できます。わざわざ一人の鵜匠に一羽の鵜を酷使させなくても、条件を整えてきちんと命令を出せば解決できるお話です。
鵜匠が影分身して沢山の鵜を放ち、確実に鮎を取るには、
１．鵜が探す川で他の鵜匠が鵜飼をしないようにする
もしくは
２．鵜が探す川で鮎の分身を取って本体を取らないようにするｗ（なんてSF？）
というような取り決めをして
１．鵜が鮎を探す縄張りを決め、その範囲内だけで取れる鮎を持ち帰らせる
もしくは
２．鮎に個体識別DNA鑑札票をつけておき、鵜には決められた鑑札番号だけの鮎を持ってくるように指示をするｗ（なんてSF？）
といった事前ルールを決めてから鵜飼をするとどうでしょう。
組み合わせとしては、上記の１と２、下記の１と２で４通りになるわけですが、どれをどう選択するかはそれぞれの本番環境や要件によって変わってくると思います。ADOに限らず、データ取得のロジックを組み立てていく際にはこれらの事を必ず考えるようにしてみてください。
川をSQLServer、鵜飼をADOにたとえた場合のそれぞれの具体的な設定とコードはまた次回ｗ