ストアド、トリガーの同時呼出

質問

SQL Server 2008 です。
在庫管理DBを作ろうとしています。

複数のクライアントから一つのレコードに更新が発生した場合を考えています。
複数のクライアントから同一のストアド(在庫引落)を読んだ場合
呼ばれたストアドは同時に複数走るのでしょうか、一つずつ走るのでしょうか?

こんな時(在庫引落)はストアドにパラメータを渡すよりも、一時テーブルに
書き込んで、トリガーで更新(引落)ってな事をした方がいいのでしょうか?
その場合トリガーも同時に走るのでしょうか?一つづつでしょうか?

複数のクライアントから更新がかかり、直接レコードを更新出来ないような
場合はSQLではどう処理するのがメジャーなんでしょうか?

オフコンでは仮想記憶って云うのがあって、そこに書き込むとバックグランドで
ウェイティングしていたプログラムが一件ずつ読み込んで更新する仕組みでした。
更新が終わると、また読込みでウェイティングする仕組みです。
複数の端末から一つの仮想記憶に書きこみ、読込みはシーケンシャルで一件ずつですので、
在庫がマイナスになることは合っても、整合性が取れなくなることはありませんでした。
こんな仕組みでSQLに移行したいと考えています。

回答No.3

jamshid6 · ベストアンサー

原則論から言えば「トリガは使わなくて済むならばできるだけ使わないようにする」が正しいです。
ただし、私はトリガーでやっていいケースはあると考えています。

・その２つのテーブルの間に極めて密な関係がある（例外なく反映させる）
・１つのテーブル以外はアプリケーションサイドで通常更新対象と認識されていない
・複数のルートでテーブル更新が掛けられる可能性がある
・ユーザがトリガーを無効にできる権限を持っていない

具体的には数十万件の取引データからリアルタイムの累積残高を取得・表示させるための残高テーブルの更新にトリガを使用したことがあります。

今回のケースはストアドでもトリガでやってもいいケースだと思いますが、以下の点は留意してください
・SQL Serverには行トリガがないので、複数更新が掛けられたときの処理を組み込む
　（複数行更新は不可とするか、全部が在庫条件を満たしたときだけＯＫとする）
・在庫がマイナスになる場合はトリガ内でRAISERRORを発行する
・呼び出し元（ストアドでもアプリでも）はエラートラップが必須

回答No.2

jamshid6

＞複数のクライアントから同一のストアド(在庫引落)を読んだ場合
＞呼ばれたストアドは同時に複数走るのでしょうか、一つずつ走るのでしょうか?

ストアドプロシージャは同時に走りますが、処理の中で同じレコードに対する排他ロックを取得できなかった方は待つことになります。だから通常はレコードをロックする時間が極力短くなるようにコーディングします。
#1さんの書かれた通り、質問者さんの懸念されている内容はDBMSの本質の問題（それが起きたらDBMSじゃないでしょうというような）な気がします。

補足

排他ロックがかかるのは解っていたのに、疑問点とやりたい事が
ごちゃ混ぜになった質問をしてしまいました。

そこで再度質問ですが、
出庫データが累積テーブルに書き込まれたらトリガーで在庫から
引き落とす仕組み（insertの数量を引落、deleteの数量を戻し)を
作ろうと考えたのですが、これは普通のやり方でしょうか?
それともストアドへキーと数量を渡し在庫の更新が完了後
累積テーブルに書き込む方がいいのでしょうか?

複数の端末から同時に同じ物を出庫されると入力画面のチェック時
は在庫不足にならなくても、更新時にマイナスになることは想定しています。
これもトリガーで在庫が更新された時に確認しマイナスの場合は
何らかのアラームになるような事を考えています。

これまでトリガーは履歴の採取にしか使っていなかったのですが、
トリガーをこんな風に利用してもいいのでしょうか?
(トリガーはこんな風に利用するものなのでしょうか?)

回答No.1

chukenkenkou

何のために、DBMSを使っているのですか？
DBMSを使う理由の一つが、排他制御で同時更新を抑止したり、トランザクションといった単位で複数の表、複数の行の更新を有効にしたり無効にしてデータの整合性が保証されることですよね？

お礼

＞何のために、DBMSを使っているのですか？

駆け出しの性で使う理由を考えて使っているわけではありません。
ＰＣの素人がエクセルを使う様な感じです・・・

再度自分の文章を読み直してみて、やりたい事と質問も合いません。
ご指摘通り通り大きな考え違いをしていたようです。

ありがとうございました。