回答編集履歴
3
修正
answer
CHANGED
|
@@ -30,7 +30,7 @@
|
|
|
30
30
|
NGだったら、組んだ手順の出番です。（心なしかブルーな気持ち）
|
|
31
31
|
|
|
32
32
|
---
|
|
33
|
-
データパッチはupdateだけじゃなくinsertやdeleteも含めて実行するケース
|
|
33
|
+
データパッチはupdateだけじゃなくinsertやdeleteも含めて実行するケースもありますが、
|
|
34
34
|
updateの検証はちょっと手間に感じます。
|
|
35
35
|
|
|
36
36
|
update文での変更は、変更する内容が変更前を元にするような場合があるので、
|
2
修正
answer
CHANGED
|
@@ -38,4 +38,6 @@
|
|
|
38
38
|
|
|
39
39
|
set a=b のbをselect文で出力して確認するようにすると手直しの手間が取られません。
|
|
40
40
|
また、そのselect文を元にupdate文を組み立てると、
|
|
41
|
-
編集内容や条件はselectで確認できているので、誤りが少なくなります。
|
|
41
|
+
編集内容や条件はselectで確認できているので、誤りが少なくなります。
|
|
42
|
+
|
|
43
|
+
insertやdeleteなどの更新系は基本selectで対象や内容を確認して、それを元にした方が誤りを防げます。
|
1
推敲
answer
CHANGED
|
@@ -1,30 +1,35 @@
|
|
|
1
1
|
失敗は付き物なので、教訓として次に生かすしかないですね。
|
|
2
|
-
|
|
3
2
|
ある程度場数を踏んでくると手順は大体同じになってきます。
|
|
4
|
-
|
|
5
3
|
個人の経験でしかありませんが、参考になれば。
|
|
6
4
|
|
|
7
|
-
1.対象データの洗い出し
|
|
5
|
+
> 1.対象データの洗い出し
|
|
6
|
+
|
|
8
|
-
|
|
7
|
+
対象となるデータがどの程度となるか、検証する。
|
|
9
8
|
全件リストよりも、パターン表を抽出して件数などを確認する。
|
|
10
9
|
|
|
11
|
-
2.本番と同等のテスト環境で、どのような結果になるかを確認する。
|
|
10
|
+
> 2.本番と同等のテスト環境で、どのような結果になるかを確認する。
|
|
12
|
-
1.でのパターン表を出力して、変更された件数が意図通りか確認。
|
|
13
11
|
|
|
14
|
-
3.必ず復元できる手順を準備
|
|
15
|
-
|
|
12
|
+
1.でのパターン表を出力して、変更された件数が意図通りか確認。
|
|
16
|
-
バックアップは確実ですが、復旧にはシステム停止/再開を伴う上、長時間となる場合が多いので、
|
|
17
|
-
最短での復旧も考慮します。
|
|
18
13
|
|
|
14
|
+
> 3.必ず復元できる手順を準備
|
|
15
|
+
|
|
16
|
+
失敗した場合の切り戻しについて準備しておかないと深みに嵌ってしまいます。
|
|
17
|
+
バックアップは確実ですが、復旧にはシステム停止/再開を伴う上、長時間となる場合が多いので、
|
|
18
|
+
最短での復旧も考慮します。
|
|
19
|
+
|
|
19
20
|
・バックアップ
|
|
20
21
|
・対象データのみの退避テーブルを作成する。 (select ・・・ into)
|
|
21
22
|
（上記テーブルからの復元用のSQLも合わせて準備)
|
|
22
23
|
|
|
23
|
-
4.緊張した面持ちで実行
|
|
24
|
+
> 4.緊張した面持ちで実行
|
|
24
25
|
|
|
25
|
-
5.結果確認
|
|
26
|
-
|
|
26
|
+
適度な緊張があった方が、失敗は少ない気がします。ガチガチでは駄目ですが。
|
|
27
27
|
|
|
28
|
+
> 5.結果確認
|
|
29
|
+
|
|
30
|
+
NGだったら、組んだ手順の出番です。（心なしかブルーな気持ち）
|
|
31
|
+
|
|
32
|
+
---
|
|
28
33
|
データパッチはupdateだけじゃなくinsertやdeleteも含めて実行するケースが殆どですが、
|
|
29
34
|
updateの検証はちょっと手間に感じます。
|
|
30
35
|
|