受注と在庫を一緒に確定するには？同時注文で確認する条件

一緒に確定する更新と、画面の仕事を分ける

データベースのトランザクションは、複数の更新をまとめて、全部が確定するか、確定しないかを扱う単位です。たとえば注文を保存し在庫を減らす仕事で、どちらか一方だけが残ると、受注担当は「どの注文で在庫が減ったのか」を説明できなくなります。一緒に成り立ってほしい条件から、まとめる更新を開発先と決めます。

PostgreSQLのTransactionsは、複数の更新を一つの成否として扱うことと、完了前の途中変更を別のトランザクションへ見せない考え方を説明しています。これはDBの機能の説明であり、会社の実装が正しくその範囲をまとめている証拠ではありません。実際にどの更新を同じ単位に入れるかを確認します。

同じ画面から始まる仕事でも、全部が同じ確定単位とは限らない

入力する、確認画面を読む、注文を確定する、メールを送るという仕事には、人の待ち時間や外部への動作も含まれます。画面の一つのボタンから始まることだけでは、すべてが同じDBのトランザクションになるとは言えません。注文と在庫の保存範囲、通知の扱いを分けて尋ねてください。

外部へ送った通知を含む途中停止や、戻せない仕事の判断は、別の例外処理の検討です。ここでは、注文と在庫を一緒に扱う条件と、確定までにほかの注文が入る条件へ焦点を合わせます。

在庫更新の後で注文保存が失敗する条件

最初は、注文保存が失敗する架空条件です。在庫更新を試みたことを、在庫が確定したことや、正しく元へ戻ったことへ読み替えないように見てください。

在庫更新後に注文保存が失敗する例。説明用の架空条件で、この例の注文票と対象の部品を対応させます。元資料の仮番号・部品記号は三例を照合する値で、操作やメニューの名前ではありません。

確認画面で見た在庫と、注文したい数量

在庫は2。注文したい数量は1。

この例で置く操作の条件

同時の別注文はない条件。在庫更新を試み、注文保存も試みる条件です。

失敗時に期待する扱い

注文保存は失敗する架空条件です。そのとき、在庫と注文をまとめて確定する期待は置きません。確定済みと表示せず、注文・在庫の両方がどう残るかを開発先と確認します。

実際の結果として残る確認

実DBの確定結果は未取得。顧客への実表示文も未取得です。

業務側が伝えたいのは、注文が保存されなかったのに在庫の減少だけが確定して残らないことです。開発先へは、在庫と注文をどの範囲で一緒に確定するか、途中失敗なら何が残り、受注担当へ何を表示するかを説明してもらいます。今回の仮条件だけでは、実DBが元へ戻ったとは判定できません。

確認する記録も二つに分けます。対象注文の保存と、同じ部品の在庫への影響を結び付けて調べます。画面にエラーが出たことだけで、両方が未確定になったとは判断しません。逆に、エラーが出なかったことだけを、整合した保存の証拠にもしません。

保存結果を照会できない場合は、すぐ同じ注文を作り直す前に、開発先が用意する調査方法と担当を確かめます。結果不明の再送で重複を避ける観点は、再送前の確認と対処で別に扱っています。

二人が同じ残り一つを見たときの確定と保留

次は、二人が同じ部品を注文する別の架空条件です。在庫を確認してから確定するまでの間に、もう一人が操作する可能性を考えます。確認画面の在庫1は、両方の注文を確定できる約束にはしません。

二人が残り一つを同時に注文する例。説明用の架空条件で、この例の注文票と対象の部品を対応させます。元資料の仮番号・部品記号は三例を照合する値で、操作やメニューの名前ではありません。

同時注文の検討条件

二人とも確認画面では在庫1を見た条件。それぞれ1を注文したい条件。同じ部品への別注文が重なります。

開発先と決める期待

一件だけを確定できる条件を、業務担当と開発先で決める案です。確認画面の在庫1を、両注文の確定保証として扱いません。

まだ分からない実処理

在庫更新を試みたか、注文保存を試みたか、注文保存の成否、実DBの確定結果、顧客への実表示文は、いずれも未取得です。

確認画面で見せる状態と、確定時に判定する状態

確認画面を開いた時点から在庫を取り置くのか、確定時に改めて条件を調べるのかで、画面の意味も業務の扱いも変わります。この資料では方式は未決です。業務担当は、確定前の表示が何を示すか、別注文が先に進んだときに誰へ何を返すかを決め、開発先へ実現方法を尋ねます。

MySQL 8.4のInnoDB Locking Readsは、通常の読み取りの後に関連更新を行う間、別のトランザクションが同じ行を変更し得ることを説明しています。読み取りと確定の間を考える根拠になりますが、この記事が案件のロック方法やSQLを決定するものではありません。

一件が進めなかったときも、次に何をすればよいかを伝える

一件だけを確定する案なら、もう一件をどの状態にするかを決めます。確定できなかったこと、保存が済んだか不明なこと、担当者が確認するため保留したことは別です。再選択を促すのか、受付担当へ渡すのか、いつ確認するのかを業務に合わせて相談します。

待機する方式でも、いつまで待つか、待ち時間が長い場合にどの表示へ移るか、結果が不明になったときに何を調べるかが必要です。待ち時間や処理件数の数値は、利用条件と実際の確認で決めます。一般的な設定名だけで、現場が待てる時間や実測性能が分かったことにはしません。

注文番号の重複は、別の条件として確かめる

在庫と注文をまとめる条件だけでは、番号をどのように作り、同じ注文の再試行をどう見分けるかまでは決まりません。三つ目は、その質問を独立させる架空例です。

注文番号の重複を確かめる例。説明用の架空条件で、この例の注文票と対象の部品を対応させます。元資料の仮番号・部品記号は三例を照合する値で、操作やメニューの名前ではありません。

この例の対象と、求めたいこと

注文したい数量は1。番号の付け方、重複を防ぐ仕組み、再試行時の照合を、別の質問として開発先へ確認します。

今回の記録で確定しない条件

確認画面の在庫、別注文の同時性、在庫更新を試みたか、注文保存を試みたか、注文保存の成否、共同で確定する期待条件、実DBの確定結果、顧客への実表示文は、いずれも未取得です。

たとえば「今日の注文件数に一を足す」という考えだけでは、二人が同じ件数を読む条件を説明できません。開発先へ、番号を決める場所、一意にする範囲、競合した場合の処理、再試行を同じ注文と照合する方法を尋ねます。資料に番号欄があることを、重複が防げている証拠にしません。

番号が重ならないことと、同じ業務の注文が二重に作られないことも分けます。異なる番号で同じ依頼が二件できる可能性まで含め、何を同じ注文とみなすか、内容を直す場合はどう扱うかをそろえます。識別の方式と確認方法は、利用する仕組みに合わせて回答を求めます。

図で、確認画面と確定時点の違いを読む

図では、注文票と在庫欄を結び、注文保存が失敗する条件で何を一緒に確定しないか、二人が在庫を見た条件で何をまだ確定と呼ばないかを見ます。実DBの結果ではなく、開発先へ確かめたい期待と問いを示す図です。

解説図を原寸で見る

図から読む判断：保存失敗の例は、在庫だけが確定して残らない条件を確認します。同時注文の例は、一件だけを確定する案と、もう一件の状態・表示を相談します。どちらが実際に成立したかや、在庫が元に戻ったかを図から補いません。

次の行動：受注担当が困る表示や残り方をIT発注担当とまとめ、開発先へ、確定する単位・競合時の結果・照会する記録を尋ねます。注文番号と再試行の照合は別の問いとして残します。図の説明を読んだだけで、本番へ再実行を行う手順にはしません。

開発先へ、成否・表示・待機の条件を尋ねる

注文と在庫が片方だけ残らない条件

「同じ注文について、在庫の減少と注文の保存はどこまで一緒に確定しますか。途中で失敗したとき、受注担当は何を見れば両方の状態を調べられますか」と尋ねます。利用するDBや保存先が分かれれば、同じ単位で扱える範囲も確認します。

在庫確認と同時注文の扱い

「確認画面で見た在庫は、どの時点の状態ですか。その後に別注文が進んだ場合、確定の判定と画面表示はどう変わりますか」と聞きます。待機・確定不可・保留・結果不明を同じ表示で済ませず、担当者が取れる次の行動まで説明してもらいます。

番号・再試行・人の対応が重なる場合

「同じ依頼をもう一度送った場合、どの情報で前の結果を照合しますか。別の担当者が手で注文を登録したときも含め、二重の注文や在庫減少をどう調べますか」と尋ねます。番号の一意性、同じ内容の再試行、変更された注文は、それぞれの意味をそろえます。

実装の説明と、利用条件で確認する結果

ロック、分離レベル、制約といった用語が回答に出たら、今回の画面とデータで何が守られ、何が待機・失敗になるかへ戻して読み合わせます。用語を列挙しただけで受け入れず、索引や更新対象、同時操作の条件、必要な権限、調査方法まで、採用する構成に合わせて説明してもらいます。

回答を、今回の範囲と期待結果へ戻す

回答で分かったことは、注文と在庫の確定条件、確認画面の意味、競合時の表示、照会の方法、番号と再試行、確認する役割へ反映します。今回の範囲に含む処理と、追加の設計・画面・運用が必要な処理を分けます。未回答の条件は未回答と残し、都合のよい実装を補いません。

「注文は確定しない」という回答でも、入力内容を保てるか、やり直しができるか、担当者へ渡すかは業務の選択です。逆に、受付として保存する案なら、確定した注文とどう区別するかを決めます。業務上の状態名と、DBが確定した単位を混同しないようにします。

外部の決済や通知も必要だと分かったら、同じDB更新に自動的に含めません。外の動作が失敗したときの状態と確認方法を別途整理します。一連の仕事が途中で止まった後に何をするかは、例外時の業務判断とつなげて検討します。

保存失敗と同時注文を分けて試験する

以下は、合意した仕様の確認方法を組み立てるための提案です。実施場所、使える注文・在庫、権限、失敗させる方法、元へ戻す方法を開発先と決めます。本番の注文や在庫を無断で変更する試験にはしません。

1. 初期状態と期待する二つの記録をそろえる。どの部品の何個を誰が注文し、成功時に注文と在庫がどう対応するかを先に決めます。画面の成功表示だけでなく、照合する記録を指定します。
2. 注文保存の失敗条件を確かめる。在庫更新と注文保存の途中で、今回の仕様に必要な失敗を用意します。片方だけ確定して残っていないか、どの表示と記録になるかを期待と比べます。単にエラーが出たことを合格としません。
3. 二人の同時操作を、別々の注文として追う。同じ部品を二人が選んだ条件で、どの時点の在庫を見て、確定時にどう判定するかを確認します。一件だけ確定する案なら、もう一件の状態・表示・次の操作も確かめます。予定した案と、実際の結果は別に残します。
4. 番号の競合と再試行を分ける。仕様で必要な範囲で、番号の競合、同じ依頼の繰り返し、内容を直した依頼の条件を選びます。注文が増えすぎないことだけでなく、在庫への影響と結果照会を対応させて見ます。
5. 期待と違う部分を具体的に返す。対象注文、初期在庫、操作した条件、期待した状態、実際に確認した記録と表示を分けて伝えます。原因を推測で決めず、修正後は関係する操作と同時条件を確かめます。

この三例の実DB確定結果と顧客への実表示は未取得です。ここに示した期待条件を、実装や試験で成功した結果に置き換えません。応答時間や同時件数も、今回の利用条件で測っていなければ未確認のままです。

まとめ：片方だけ残っては困る二つの記録から始める

受注と在庫の設計は、トランザクションという機能名を指定するだけでは終わりません。同じ注文で一緒に確定する更新を決め、確認画面で見た在庫と確定時点の状態を区別し、競合した注文をどう表示・保留するかまで開発先とそろえます。

注文番号の一意性と、同じ依頼の再試行も別の条件です。回答で今回の範囲と期待結果を更新し、保存失敗・同時操作・番号の競合を区別して、注文と在庫の実際の残り方を確認してください。

最初の一歩：受注担当と一つの注文を選び、「注文が保存されないときに在庫だけ減ってよいか」「確認画面の後で別注文が入ったら何を表示するか」を読み合わせます。答えが決まらない所を、IT発注担当から開発先への質問と確認条件にします。