ネットワーク操作を待っている更新を選択しますか？

Question

私はオンラインショップを実装しています。

オーダーレコードのロックをselect for updateにしても問題ないのですか？
以下は、ロックと見なされる注文状態の変更点です。

• 支払処理：買い手や売り手は順番
• 注文確認を取り消す：：その買い手はキャンセルできませんので、売り手は順序を確認し、購入者が注文を支払う、注文はキャンセルオーダー
paidに waiting-for-paymentから行きます注文はこれ以上なくなります

たとえば、買い手が注文をキャンセルし、売り手が注文を確認したとき。
ロックしないと、買い手がキャンセルを実行し、売り手が注文を同時に確認する可能性があります。
しかし、ロックすると、買い手はキャンセルするか、売り手が確認します。

これまでのところ、私の質問はこれです：ネットワーク操作（支払い処理）を待っている注文インスタンスをロックすることは、テーブルの行だけであってもあまりにも大きなパフォーマンスオーバーヘッドになりますか？

私はpostgresqlを使用しています

Answer 1

ビジネスロジックを実装するためにデータベースロック機構を使用しています。それは悪い考えです。

[Transaction State]フラグフィールドを導入し、それを分析してBusiness Logicを適用します。これにより、複数の異なるトランザクション状態と複雑なビジネスルールを各状態に適用できるビジネスシナリオに柔軟性を持たせることができます。

トランザクション処理履歴テーブルを使用して、トランザクション状態の全ログを時間の経過と共に記録することをお勧めします。

更新： ステータスは、履歴と一致する場合にのみ変更する必要があります。支払いが失敗した場合は、支払われた注文をマーキングしてロールバックする必要はありません。

変更が行われるたびに、操作が実行される前に確認された要件のリストが存在する必要があります。バスケットに商品があることを確認してくださいとお客様が確認した配達アドレスとの合計価格はより多く、の前にお支払いを要求しています。

注文状態の変更に関する無限のシナリオがあり、履歴全体を含む可能性のある状態ごとに別々のコードを持つことは実用的ではありません。入金確認または非配信またはサプライヤーまたは他の状況の任意の数から到着事前に注文した商品の顧客のリターンまたは交換後の発送のために利用可能になることができます注文。

各注文の注文状態の完全な履歴を把握し、ビジネスシナリオを分析し、それに応じて最適な次のアクションを選択する方が良い。