回答編集履歴
1
修正と追記
answer
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
テーブル設計時にレコードの推移をログとして残したい場合に、何度かupdateとdeleteの無いテーブル定義をしたことがあります。（リンク先はかなり入り組んでそうなので、さっと斜めに読んでそっと閉じました。）
|
|
2
2
|
|
|
3
|
-
あるものは、データ更新が複雑でレアケース整合性が取れないデータ登録がされる場合があり、適切に修正するために変更履歴をとっておくという方針だったりしました。
|
|
3
|
+
あるものは、データ更新が複雑でレアケースで整合性が取れないデータ登録がされる場合があり、適切に修正するために変更履歴をとっておくという方針だったりしました。
|
|
4
4
|
|
|
5
5
|
DBのあるべき性質特性の一つに、同じ内容のデータは一箇所にしか存在すべきではないというものがあります。これを原子性と呼びます。
|
|
6
6
|
|
|
@@ -14,4 +14,13 @@
|
|
|
14
14
|
|
|
15
15
|
④・⑤は通常のCRUDを利用するので、DB登録時にログテープルにも書き込もうということ以上の意味はないと思います。
|
|
16
16
|
|
|
17
|
-
この方法では、当然ストレージを圧迫し、DBのレスポンスを低下させます。使用する際は限定的に行うか、DBMSをバッサリ諦めファイルシステムで管理するなど思いっきった方法をとるかする必要があります。
|
|
17
|
+
この方法では、当然ストレージを圧迫し、DBのレスポンスを低下させます。使用する際は限定的に行うか、DBMSをバッサリ諦めファイルシステムで管理するなど思いっきった方法をとるかする必要があります。
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
追記－気が付いたのですが、私が話した実例は基本的には過去のデータを利用する場合があるからという場合なので、そもそもdeleteは許されないケースですね。
|
|
21
|
+
|
|
22
|
+
そういう意味で、[Jxckさんのエントリ](http://qiita.com/Jxck_/items/156d0a231c6968f2a474)とほぼ同意見で、updateでいけるところはそのままでいいよというのがあります。また、修正のために履歴を残していたケースですが、適切なキーを付けたログでもよかったなあと思います。
|
|
23
|
+
|
|
24
|
+
別の場合で、頻度が多くないがユーザーが参照する場合があるので履歴でとっているというケースもあります。（これには、参照画面がある場合と調査依頼が必要な場合とがあります。）
|
|
25
|
+
|
|
26
|
+
まあ、update・deleteを使わないのは、工夫の余地はあるけれど、それで影響が出ない程度のものに限定して使っていました。
|