質問編集履歴
1
詳細(背景)を追記しました。
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -13,4 +13,23 @@
|
|
|
13
13
|
バリデートで実現というのもしっくりきません。
|
|
14
14
|
|
|
15
15
|
何か良い方法があったら教えてください。
|
|
16
|
-
よろしくお願いします。
|
|
16
|
+
よろしくお願いします。
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
### 追記です(11/14)
|
|
20
|
+
- レアケースなのでなるべくわざわざロックはしたくないです。
|
|
21
|
+
(主キーかぶりのときはエラー画面になれば十分。データの破壊だけは避けたい。)
|
|
22
|
+
|
|
23
|
+
- システムとしてはデータの更新も必要ですので対象のTableクラスでUPDATEは禁止したくないです。
|
|
24
|
+
(「UPDATE禁止のTableクラス」「UPDATE禁止じゃないTableクラス」の2つ作るってのも
|
|
25
|
+
微妙ですよねぇ…)
|
|
26
|
+
|
|
27
|
+
- 「INSERTするつもりで既存のレコードを上書きしてしまう事故」は
|
|
28
|
+
次の2パターンを想定しています。
|
|
29
|
+
|
|
30
|
+
0. 新しいレコードの主キーを発行する仕組みにバグがあり
|
|
31
|
+
重複した主キーが発行されてしまった場合、既存データが破壊されてしまう。
|
|
32
|
+
|
|
33
|
+
0. 新しいレコードの主キーを「既存の最大ID＋1」で発行する場合において、
|
|
34
|
+
アクセスが集中し2つのリクエストで同一主キーが発行されると
|
|
35
|
+
先にINSERTされたレコードが上書きされてしまう。
|