Способы реализации контроля версий данных в PostreSQL - PullRequest
Новая
       7

Способы реализации контроля версий данных в PostreSQL

12 голосов
/ 15 ноября 2010

Можете ли вы поделиться своими мыслями о том, как бы вы реализовали управление версиями данных в PostgreSQL.(Я задавал похожий вопрос относительно Cassandra и MongoDB . Если у вас есть какие-либо мысли о том, какой дБ лучше для этого, поделитесь)записи в простой адресной книге.Записи адресной книги хранятся в одной таблице без связей для простоты.Я ожидаю, что история:

  • будет использоваться нечасто
  • будет использоваться одновременно, чтобы представить ее в виде "машины времени"
  • там выиграно 'Для одной записи может быть больше версий, чем несколько сотен.
  • история не устареет.

Я рассматриваю следующие подходы:

  • Создание новой таблицы объектов для хранения истории записей с копией схемы таблицы адресной книги и добавление метки времени и внешнего ключа в таблицу адресной книги.

  • Создание вида схемы меньшетаблица для хранения изменений в записях адресной книги.Такая таблица будет состоять из: AddressBookId, TimeStamp, FieldName, Value.Таким образом, я буду хранить только изменения в записях, и мне не нужно будет синхронизировать таблицу истории и таблицу адресной книги.

  • Создать таблицу для хранения разделенной (JSON) адресной книгизаписи или изменения в записи адресной книги.Такая таблица будет выглядеть следующим образом: AddressBookId, TimeStamp, Object (varchar).Опять же, это схема меньше, поэтому мне не пришлось бы синхронизировать таблицу истории с таблицей адресной книги.( Это смоделировано после простого управления версиями документов с помощью CouchDB )

Ответы [ 3 ]

2 голосов
/ 15 ноября 2010

Я делаю что-то вроде вашего второго подхода: иметь таблицу с фактическим рабочим набором и историю изменений (timestamp, record_id, property_id, property_value).Это включает в себя создание записей.Третья таблица описывает свойства (id, property_name, property_type), которые помогают в преобразовании данных выше в приложении.Таким образом, вы также можете очень легко отслеживать изменения отдельных свойств.

Вместо временной метки вы можете также иметь int-подобный тип, который вы увеличиваете для каждого изменения для record_id, так что у вас есть фактическая версия .

2 голосов
/ 15 ноября 2010

Я версионирую данные глоссария, и мой подход был довольно успешным для моих нужд.По сути, для записей, для которых необходимо управление версиями, вы разделяете набор полей на постоянные поля и поля, зависящие от версии, создавая две таблицы.Некоторые из первого набора также должны быть уникальными ключами для первой таблицы.

Адрес id [pk]полное имя [великобритания]день рождения [великобритания] Версия
id [pk]address_id [великобритания]отметка времени [великобритания]адрес

Таким образом, вы получаете адрес субъекта, определяемый полным именем и днем ​​рождения (не должен меняться при управлении версиями) и версионные записи, содержащие адреса.address_id должен быть связан с Address: id через внешний ключ.С каждой записью в таблице версий вы получите новую версию для субъекта Address: id = address_id с определенной отметкой времени, в которой вы можете иметь ссылку на историю.

2 голосов
/ 15 ноября 2010

Вы можете иметь start_date и end_date.

Когда end_date равно NULL, это фактическая запись.

...