Способы реализации управления версиями данных в PostreSQL

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

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

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

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

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

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

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

Ответы

Ответ 1

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

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

Ответ 2

У вас могут быть start_date и end_date.

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

Ответ 3

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

Адрес
id [pk]
fullname [uk]
день рождения [uk]

Версия
id [pk]
address_id [uk]
timestamp [uk]
адрес

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