ソフト削除とソフト更新のみをサポートするDB設計パターンの名前は何ですか？
リレーショナルデータベースには、レコードを更新するとタイムスタンプやステータスが異なる新しいレコードが作成されるDB設計があると聞きました。また、削除は一時的削除になります（ステータスまたは発効日を過去の日付に更新します）。実際にはレコードは削除されません。そのようなデザインパターンに名前があるか知りたいのですが。このようなパターンを使用する必要があるのはどのシナリオですか？
あなたが探しているコンセプトはおそらく「データのバージョン管理」でしょう。特定のエンティティに加えられたすべての変更を追跡することが監査にとって重要な場合に役立ちます（構成パラメーター、ベンダーの銀行口座、または一般的な会計記録など）。 Stack Exchangeの回答では、考えられるすべてのシナリオをリストするのは現実的ではありません。
ここ は、特定のタイプのデータベース（MariaDB）でautomaticデータのバージョン管理がどのように機能するかを説明する記事の例です。このような記事は、車輪を再発明することからあなたを救うかもしれません。非常に単純な場合を除いて、独自のバージョン管理システムを導入したくない場合。
これは、かなり粗雑な監査証跡と呼ばれます。
よく使用される用語はテンポラルテーブルです。データには、行が使用された時刻とその行が現在の行でなくなった時刻を保持する追加の列が含まれています。これらの列は、開発者の制御下で明示的にすることも、DML操作で開始値と終了値を設定するときにシステムで生成することもできます。
時間は、クロック時間またはCPUティックやログシーケンス番号（LSN）などの内部測定によって測定できます。測定値はシステムの再起動後に影響を受けないため、クロックが推奨されます。また、システム間の妥当な精度と比較することもできます。クロックを使用する場合、行に対する同時更新を区別できるように十分な解像度を確保することが重要です。
履歴は、現在の値と同じディスク構造または別の構造に保存できます。通常のテーブルとトリガーを使用して一時ストアを実装することが可能です。
データベース内のすべてのテーブルに一時的な機能がある場合、DBは以前の任意の時点と同じようにクエリできます。これにより、たとえば、同時更新（HTAP）によるポイントインタイムレポートが可能になります。このようなスキームは、専用のレポートインフラストラクチャを排除することで、レポートの鮮度を高め、コストを節約できます。
タプルのバージョン管理？すなわち。 https://en.wikipedia.org/wiki/Tuple-versioning
いつ使うかという質問は「場合によります」。多くのシステムでは、状態へのすべての変更を追跡および/または復元できることが重要ですが、コストはかなり高くなります（スペースと操作の両方）。