42

(データベース スキーマのバージョン管理とは関係ありません)

多くの場合、データベースとやり取りするアプリケーションには、多くのテーブルのデータで構成されるドメイン オブジェクトがあります。アプリケーションが、CVS の意味で、これらのドメイン オブジェクトのバージョン管理をサポートするとします。

任意のドメイン オブジェクトについて、この要件を処理するデータベース スキーマをどのように設計しますか? 共有する経験はありますか？

4

9 に答える 9

22

改訂の要件について慎重に検討してください。コードベースに広範な履歴追跡が運用システムに組み込まれると、非常に複雑になります。 スキーマが 1000 を超えるテーブルで実行されることが多い保険 引受 システムは、これに特に適していません。クエリも非常に複雑になる傾向があり、これがパフォーマンスの問題につながる可能性があります。

履歴状態が実際にレポートにのみ必要な場合は、履歴を追跡するためにデータ ウェアハウス構造が背後にぶら下がっている「現在の状態」のトランザクション システムを実装することを検討してください。 ゆっくりと変化するディメンションは、アドホックな履歴追跡メカニズムを運用システムに直接埋め込もうとするよりも、履歴状態を追跡するためのはるかに単純な構造です。

また、Changed Data Captureは、所定のレコードに変更が加えられている「現在の状態」のシステムのほうが簡単です。レコードの主キーは変更されないため、同じエンティティの異なるバージョンを保持するレコードを一致させる必要はありません。一緒。効果的な CDC メカニズムにより、増分ウェアハウス ロード プロセスがかなり軽量になり、非常に頻繁に実行できるようになります。履歴の状態を最新の状態で追跡する必要がない場合 (ほとんど、しかし完全ではない、矛盾した表現)、これは、アプリケーションに直接組み込まれた完全な履歴追跡メカニズムよりもはるかに単純なコード ベースを使用する効果的なソリューションとなる可能性があります。

于 2008-09-24T08:29:15.557 に答える
12

これまで私がこれに使用した手法は、データベースに「世代」の概念を持たせることでした。変更するたびに、データベースの現在の世代番号が増加します。Subversionを使用する場合は、リビジョンを検討してください。各レコードには、2つの世代番号が関連付けられています（テーブルに2つの追加の列）。つまり、レコードの有効性が開始される世代と、レコードの有効性が停止する世代です。データが現在有効である場合、2番目の数値はNULLまたはその他の一般的なマーカーになります。

したがって、データベースに挿入するには：

  1. 世代番号をインクリメントします
  2. データを挿入します
  3. そのデータの存続期間に、有効なfromと有効なtoのNULLをタグ付けします

一部のデータを更新する場合：

  1. 変更しようとしているすべてのデータを現在の世代番号に対して有効としてマークします
  2. 世代番号をインクリメントします
  3. 現在の世代番号で新しいデータを挿入します

削除は、データを現在の世代で終了するものとしてマークするだけの問題です。

データの特定のバージョンを取得するには、対象の世代を見つけて、それらの世代バージョン間で有効なデータを探します。

例：

人を作成します。

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |NULL|

電話番号を更新します。

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |1   |
|Fred|1 april|555-43534|2   |NULL|

フレッドを削除：

|Name|D.O.B  |Telephone|From|To  |
|Fred|1 april|555-29384|1   |1   |
|Fred|1 april|555-43534|2   |2   |
于 2008-09-24T07:49:35.823 に答える
3

厳密なバージョン管理の代わりに、データを現在と履歴の2つのテーブルに分割することもできます。

現在のテーブルにはすべてのライブデータがあり、組み込みのすべてのパフォーマンスの利点があります。変更を加えると、最初に現在のデータが、いつ変更されたかを示す日付マーカーとともに関連する「履歴」テーブルに書き込まれます。

于 2008-09-24T07:59:43.910 に答える
2

Hibernate JBoss Enversを使用している場合は、オプションになる可能性があります。@Audited履歴を保持するには、クラスに注釈を付けるだけです。

于 2010-08-12T08:11:40.383 に答える
1

すべてのバージョンに共通の情報を含むマスターテーブルにマスターレコードが必要です。

次に、各子テーブルは、主キーの一部としてマスターレコードID+バージョン番号を使用します。

マスターテーブルがなくても実行できますが、私の経験では、SQLステートメントが非常に乱雑になる傾向があります。

于 2008-09-24T07:57:10.577 に答える
0

簡単で確実な方法は、テーブルにバージョン列を追加してオブジェクトのバージョンを保存し、そのバージョン番号に基づいて適切なアプリケーション ロジックを選択することです。このようにして、わずかな費用で下位互換性も確保できます。どれがいつもいいの

于 2008-09-24T08:31:21.807 に答える
0

ZoDB + ZEO は、任意の時点への完全なロールバックをサポートするリビジョン ベースのデータベースを実装します。それをチェックしてください。

悪い点: Zope で結ばれています。

于 2008-09-24T08:32:48.183 に答える
0

オブジェクトがデータベースに保存されると、そのオブジェクトを何度でも変更できます。オブジェクトが変更された回数を知りたい場合は、このバージョン管理の概念を適用する必要があります。

バージョン管理を使用するときはいつでも、オブジェクトがデータベースに初めて保存されるたびに、hibernate はバージョン番号をゼロとして挿入します。その後、休止状態は、その特定のオブジェクトで変更が行われるたびに、そのバージョン番号を自動的に 1 ずつインクリメントします。このバージョン管理の概念を使用するには、アプリケーションに次の 2 つの変更を加える必要があります。

Add one property of type int in our pojo class.

In hibernate mapping file, add an element called version soon after id element
于 2015-06-03T10:29:19.963 に答える