Способы реализации версий данных в Potresql

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

Вы могли бы иметь start_date а также end_date.

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

Answer 3

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

Адрес
ID [PK
FullName [Великобритания
день рождения [Великобритания

Версия
ID [PK
address_id [Великобритания
TimeStamp [Великобритания
адрес

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