Пути реализации версионности данных PostreSQL

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

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

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

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

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

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

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

12
database-versioning postgresql

3 ответов

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

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

2

мог бы start_date и end_date.

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

2

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

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

версия
id [pk]
address_id [uk]
метка времени [uk]
адрес

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

2