PostgreSQL での同時挿入について

がるがるさんの書き込み (2003-11-28 15:05) より:

現在時刻(通算秒)-現在時刻(マイクロ秒)-プロセスID

スレッドが極端に多い場合に一応ひっかかりますが、その辺はINSERTでチェックすれば、プライマリKeyで引っかかるので検出が可能です。
そんなに激しくないシステムの場合、マイクロ秒を省いたり、プロセスIDを省いたりしても問題なく動きます。

で、今回の場合、私ならトランザクションは使わないです。
なんでかってぇと、周囲と重複して困るのは発注IDのみで、それならトランザクションで切らなくても、INSERTできればOK、出来なければNGで容易に判定が出来るからです。

・まずは受注テーブルにINSERTをして
・問題が無ければ受注明細テーブルにのんびりINSERTして

で、楽に流せると思います。

がるがるさんの書き込み (2003-11-28 15:05) より:
がると申します。
…なんていうか、たわごとなので軽く流し読みしていただければ

どうも、DBのシリアル機能が(DBMS毎に差異があるという点を含めて)苦手で。
そういう機能を「まったく使わずに」実装することがよくあります。
で、そういった実装のうち「もっともシンプル(単純)な方法」を、軽く。

knockさんの書き込み (2003-11-28 15:14) より:
なるほど、トランザクションにこだわらずに受注ID レベルでうまくユニークな値を
作るという感じでしょうか。
ちょっと気になったのですがこの場合には、受注テーブルにINSERTをした受注ID と
受注明細テーブルにINSERTする受注ID との関連付けはどのように行うのが
よろしいのでしょうか。

なんとなくトランザクションを使わないと処理の単位(?)がなくなってしまって
個人的には怖い印象を持ちました。
またこのような方法はよく用いられるのでしょうか？

プリンスさんの書き込み (2003-11-28 15:41) より:
うーん？トランザクションとはシリアル機能を実現するわけではなく、
ACIDを保障するものだと思ったんですが？
(もちろんオラクルの場合、トランザクションのアイソレーションレベルをシリアライザブルにすることで楽観的ロックが出来ますけど)
つまり、ここで重要なのは受注ヘッダと受注明細に対するINSERT文をアトミックにすることにあります。たとえば、受注ヘッダにINSERTしたあとに、データベースが落っこちたら、受注ヘッダにはレコードはあるけど、受注明細には存在しないことになり、
ACIDを破ることになります。よく引き合いに出されるのは、銀行等の口座振替で普通口座から当座にお金を移動するときや、口座振込みの出金、入金などです。トランザクションなくしてACIDを実現することは出来ないんでは？といいますか、トランザクションとはACIDを実現することのように思えます。
口調が強く感じましたらごめんなさい。

がるがるさんの書き込み (2003-11-28 16:31) より:

つまり、私が気にしているポイントは
・ACIDが破られるか否か
よりは
・ACIDが破られた時に容易に発見できるか？
ということになるかなぁ、と思います。
まぁ、詳細テーブルへのINSERTの途中で落ちてしまえば、中途半端にしろ全部にしろデータがすっ飛ぶことに変わりは無いので(こういうときのために、Logはとっても重要です)。
データのチェックをして「このデータはおかしい」ということさえわかれば、中途半端にデータが入っていてもそんなに問題ないケースが多いと私は思っています。

集計とかを考えるなら、cronあたりで１日一回くらい、データを掃除すればよいし。そうすると「危ないデータ」が識別できるからアラートもだせるので。

上記のような理由から、トランザクションを使わなくてもできる、という風な話を持ち出しています。
多分、私のテリトリー上の問題も大きいと思うのですが。トランザクションは、便利である分色々な意味で「コストの高い」処理なので、使わずに回避できる限りは可能な限り回避したい、というスタンスを私はとっています。

「なんか変〜」という反応は大歓迎ですので、じゃかすか突っ込んでください(笑

アティさんの書き込み (2003-11-28 14:10) より:

knockさんの書いた場合も、安全だと思いますよ。
curvalで取得される値は、自セッションで取得された最新の値ですから。