質問編集履歴
1
詳細(背景)を追記しました。
test
CHANGED
File without changes
|
test
CHANGED
@@ -29,3 +29,41 @@
|
|
29
29
|
何か良い方法があったら教えてください。
|
30
30
|
|
31
31
|
よろしくお願いします。
|
32
|
+
|
33
|
+
|
34
|
+
|
35
|
+
|
36
|
+
|
37
|
+
### 追記です(11/14)
|
38
|
+
|
39
|
+
- レアケースなのでなるべくわざわざロックはしたくないです。
|
40
|
+
|
41
|
+
(主キーかぶりのときはエラー画面になれば十分。データの破壊だけは避けたい。)
|
42
|
+
|
43
|
+
|
44
|
+
|
45
|
+
- システムとしてはデータの更新も必要ですので対象のTableクラスでUPDATEは禁止したくないです。
|
46
|
+
|
47
|
+
(「UPDATE禁止のTableクラス」「UPDATE禁止じゃないTableクラス」の2つ作るってのも
|
48
|
+
|
49
|
+
微妙ですよねぇ…)
|
50
|
+
|
51
|
+
|
52
|
+
|
53
|
+
- 「INSERTするつもりで既存のレコードを上書きしてしまう事故」は
|
54
|
+
|
55
|
+
次の2パターンを想定しています。
|
56
|
+
|
57
|
+
|
58
|
+
|
59
|
+
0. 新しいレコードの主キーを発行する仕組みにバグがあり
|
60
|
+
|
61
|
+
重複した主キーが発行されてしまった場合、既存データが破壊されてしまう。
|
62
|
+
|
63
|
+
|
64
|
+
|
65
|
+
0. 新しいレコードの主キーを「既存の最大ID+1」で発行する場合において、
|
66
|
+
|
67
|
+
アクセスが集中し2つのリクエストで同一主キーが発行されると
|
68
|
+
|
69
|
+
先にINSERTされたレコードが上書きされてしまう。
|