データ変更の効果的な管理

対照的に、一時的な機能なしで使用する従来のデータベースは、現在のデータベースと呼ぶことができます。 。

現在のデータベース 、一時的なサポートを実装しようとすると、さまざまなアプローチでさまざまな方法で失敗する可能性があります。

• ワンテーブルアプローチ。 変更が必要な場合は、UPDATEsを実行します 元のレコードにあり、ある種の自家製のトリガー/監査ロジックがない限り、履歴トレイルはありません。監査/変更ログがある場合でも、変更履歴を再構築するには、醜い掘り下げを行う必要があります。

• 2つのテーブルによるアプローチ。 インプレースで変更を行う代わりに、データを2つのテーブルに分割します。1つはベース/元のレコード（予約など）を含み、もう1つは変更/変更/デルタ用のテーブルです。そうすれば、少なくとも元のデータは保持されますが、変更を重ねて元のデータを表示するには、複雑なロジックを作成する必要があります。 一部だけが必要な場合はさらに悪化します 適用された変更の。

• 事前計算された結果テーブルアプローチ 。 3つ以上のテーブルを保持します：ベースレコード、変更、および常に結果を取得しようとするテーブル（ベース+変更を最新に保つ）。 INSERTsを実行するたびに、この計算を実行するためのトリガーとプロシージャを作成してください。 、およびHeavenは、UPDATE またはDELETE が必要です。セットアップは壊れやすく、デッドロックやロールバックなどの同期が外れる可能性があります。トリガー/プロシージャを使用してDB内でこれを行わない場合、結果の計算をアプリケーションコードに実装しようとする可能性がありますが、幸運を祈ります。マルチスレッドのコンシューマーでは醜くなる可能性があります。それでも、一部だけでは、結果に簡単にアクセスすることはできません。 適用された変更。

結論： MySQLに限定されていない場合は、一時的なサポートが組み込まれているDBの使用を検討する必要があります。それ以外の場合は、ホイールを再実装します。