# DB音痴が書いてます。突っ込みどころ満載だと思います。
# ヘタレなりに精一杯考えているので、生暖かい目で見つめてやってください。
何らかのデータをDBに登録する画面を考えます。
登録前にデータをチェックします。
書式エラーのような単純なものなら、UI層だけで対応可能です。
ただ、コードの重複エラーのようなものの場合、DBを見に行かないと判断できません（画面からコードを入力させることもあります）。
全てのチェックをパスして、（ハードウェアエラー等の予期できないエラーが発生しない限り）確実に登録に成功する状態にしてから「登録してもよろしいですか？」という確認を出すのが、（少なくとも今の仕事では）好まれています。
途中チェックで引っかかった場合は、「○○がダメなので登録できません」と出します。
「登録してもいいですか？」→「○○がダメなので登録できません」という流れは嫌われます。
相手は複数のクライアントからアクセスされるDBサーバですから、排他制御をしなければなりません。
単純なチェックだと、チェックした時点から実際に登録する時点までに、他の人がデータを更新してしまって、登録NGになるケースがあり得ます。
他人のINSERTを防ごうと思ったら、対象テーブル全てをテーブルロックするしかないでしょうか。
しかし、ロックはリスクを伴います。
例えば、上記のような実装で、「登録してもいいですか？」というメッセージが出ている間はロックを維持していなければなりませんから、馬鹿なオペレータがメッセージボックスを出したまま放置してしまったりすると、他のオペレータの仕事が止まります。
「おいロック掴んでるの誰だー！？」「あ、すいません俺です」「ったく気をつけろ！」みたいな会話が飛び交います。
ロックは最小限にしたいものです。
DBならロックという手がありますが、ファイルの場合はそうも行きません。
ファイルの有無を確認して、無ければ作るなどという実装は、確認してから作るまでの間にロックをかけることができないため、試しに作ってみて、できたかどうかで判定しなければなりません。
この考えをDBに持っていくとどうでしょう？
つまり、「これから登録しようとしているコードが登録済みかどうか調べ、無ければテーブルをロックする」代わりに、「試しに登録してみて、エラーが出たらコード重複と判断する」というものです。
この場合、「登録してもよろしいですか？」というメッセージが出ているときには、既に登録作業は全て終わっており、このメッセージは「コミットしてもよろしいですか？」という意味になります。
ただ、UIからDBに、登録リクエストとコミットリクエストを分けて投げなければいけないという欠点はあります。
データチェックは「登録してもよろしいですか？」というメッセージを出す前に全て終わらせておくという考えが良くないのでしょうか。
こういう場合、どうやるのが定番なんでしょう？