リビジョン、または行のスナップショット (およびそれらの関係) をデータベースに保持するための適切なプロセスを探しています。
たとえば、eコマースプラットフォームを考えてみましょう-
- 顧客が注文を作成します。注文は、請求先住所と配送先住所に関連付けられています。
- この顧客は、プロファイルのアドレス帳の住所を変更します。
- 元の注文の住所は変更しないでください。
いくつかの概念を見てきました。1 つはテーブルの複製、もう 1 つはテンポラル データベース、もう 1 つはリビジョン ID とアクティブ フラグの保持です。
私のアプリケーションに最適/最適な解決策を誰も私に教えてくれないことを感謝していますが、それは意見などに開かれた問題であるため、誰かがおそらく比較によって利点/欠点を実証できることを望んでいました. SO に関する多くの質問と、さまざまな実装に関するかなりの数の記事を読みましたが、それぞれのアイデアを実際に比較したり、最適な場所を示したりするものはありません。以下に、それぞれの概念についての私の理解を概説します。
テーブルの複製
スナップショットを作成する必要があるデータに関連する行に情報を格納します。つまり、オンライン ストアの注文テーブルの列に住所を保持します。
利点
- データは明確に関連するテーブルに分割され、結合などは必要ありません。
- 以下の概念で必要とされるように、アクティブな行のみを選択する必要はありません。
- 行にタイムスタンプが付けられていると仮定すると、テンポラル データベースの利点のほとんどが維持されます。
短所
- 複製
- スキーマの (複数のテーブルがリビジョンをアップしている場合に特に問題があります)
- ORM を使用する場合のモデルの。
- スナップショット ピースのデータが変更されておらず、再利用されている場合のデータの。つまり、10 回の注文が行われた場合、アドレスは 11 回 (注文 + 現在) 保存されます。
- 関連するテーブルへの挿入を処理するために必要な追加のコード。
テンポラル データベース/アクティブまたは現在の行フラグ
「時間認識」のデータベース行。つまり、そのコンテキストは 2 つの日時の間の時間です。データは、時間コンテキストがテンポラル テーブルの時間コンテキストの間にある場合に結合できます。
利点
- スキーマまたはモデルの重複はありません。変更は 1 か所で行われます。
- ORM モデルは、新しい行の作成、アクティブとしてのマーク付けなどをシームレスに処理できます。
- 変更が行われていない行は複製されません。つまり、1 つのアドレスへの 10 の注文は、アドレスを 1 回保存します。
短所
- join/where 句で「アクティブな」行を選択する必要があるため、クエリがより複雑になります。
- テーブルは、定期的に選択/呼び出されない履歴データでいっぱいになります。
一時的に変更された列のみを保存します。
すべてのテーブルへの変更を追跡するテーブルを用意し、それが関連する行と、それが時間的に有効な時期を記録します。
利点
- 変更されていないデータが複製されないため、リビジョンに関して最適化されたストレージ。
短所
- 列のバージョンを他のデータと組み合わせるには、はるかに複雑なクエリを実行します。
SOに関する次の質問とこれらの他のリソースをすでに見ました
編集: この投稿に特定の DBMS のタグを付けていない理由は、理想的にはプラットフォームとして可能な限り多くのプラットフォームで動作するコンセプトを望んでいるためです。現時点では DBMS に依存せず、抽象化レイヤーにより MySQL と動作できます。 MSSQL ですが、将来的には他のものもサポートする予定です。