15

PostgreSQLでデータバージョニングをどのように実装するかについての考えを共有できますか？（ CassandraとMongoDBに関して同様の質問をしました。どのデータベースがそのために優れているかについて何か考えがあれば、共有してください）

単純な名簿のレコードをバージョン管理する必要があるとします。名簿のレコードは、簡単にするために関係なしで1つのテーブルに格納されます。私はその歴史を期待しています：

  • 使用頻度は低くなります
  • 「タイムマシン」方式でそれを提示するために一度に使用されます
  • 1つのレコードに対して数百を超えるバージョンはありません。
  • 履歴は期限切れになりません。

私は次のアプローチを検討しています。

  • アドレス帳テーブルのスキーマのコピーを使用してレコードの履歴を格納する新しいオブジェクトテーブルを作成し、アドレス帳テーブルにタイムスタンプと外部キーを追加します。

  • 名簿レコードへの変更を格納するための一種のスキーマレステーブルを作成します。このようなテーブルは、AddressBookId、TimeStamp、FieldName、Valueで構成されます。このようにして、レコードへの変更のみを保存し、履歴テーブルと名簿テーブルの同期を維持する必要がなくなります。

  • セラライズド（JSON）名簿レコードまたは名簿レコードへの変更を保存するテーブルを作成します。このようなテーブルは次のようになります：AddressBookId、TimeStamp、Object（varchar）。繰り返しますが、これはスキーマが少ないので、履歴テーブルとアドレスブックテーブルの同期を維持する必要はありません。（これは、CouchDBを使用した単純なドキュメントのバージョン管理をモデルにしています）

4

3 に答える 3

4

私はあなたの2番目のアプローチのようなことをします：実際のワーキングセットと変更（タイムスタンプ、record_id、property_id、property_value）の履歴を持つテーブルを持っています。これには、レコードの作成が含まれます。3番目の表は、プロパティ（id、property_name、property_type）について説明しています。これは、アプリケーションの上位でのデータ変換に役立ちます。したがって、単一のプロパティの変更を非常に簡単に追跡することもできます。

タイムスタンプの代わりに、record_idごとに変更ごとにインクリメントする、intのようなものを使用することもできます。これにより、実際のバージョンが得られます。

于 2010-11-15T15:43:46.810 に答える
2

あなたが持っている可能性がstart_dateありend_dateます。

end_dateがNULLの場合、それは実際のレコードです。

于 2010-11-15T15:23:00.280 に答える
2

私は用語集データをバージョン管理していますが、私のアプローチは私のニーズに対してかなり成功しました。基本的に、バージョン管理が必要なレコードの場合、フィールドセットを永続フィールドとバージョン依存フィールドに分割して、2つのテーブルを作成します。最初のセットの一部は、最初のテーブルの一意のキーでもある必要があります。

アドレス
ID[pk]
フルネーム[uk]
誕生日[uk]

バージョン
ID[pk]
address_id[uk]
タイムスタンプ[uk]
アドレス

このようにして、氏名と誕生日（バージョン管理によって変更されるべきではない）によって決定される住所の件名と、住所を含むバージョン管理されたレコードを取得します。address_idは、外部キーを介してAddress：idに関連付けられている必要があります。バージョンテーブルの各エントリで、特定のタイムスタンプを持つサブジェクトAddress：id = address_idの新しいバージョンを取得します。これにより、履歴参照を取得できます。

于 2010-11-15T16:35:09.253 に答える