Управление версиями в базе данных - PullRequest
0 голосов
/ 01 мая 2018

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

Пока что я решил использовать следующий подход.

  1. Не разрешать обновления.
  2. Каждый раз, когда производится обновление, создайте новый запись в таблице.

Однако я не знаю, какой дизайн структуры базы данных лучше для этого изменения.

Текущая структура

Первичный ключ: id

id(int) | amount(decimal) | other_columns 

Первый подход

Составной первичный ключ: id, версия

id(int) | version(int) | amount(decimal) | change_reason 
 1      | 1            | 100             | 
 1      | 2            | 20              | correction

Второй подход

Первичный ключ: id

Индекс уникальности для [origin_id, version]

id(int) | origin_id(int) | version(int) | amount(decimal) | change_reason 
 1      | NULL           |  1           | 100             | NULL
 2      | 1              |  2           | 20              | correction

Ответы [ 3 ]

0 голосов
/ 02 мая 2018

Лучший способ - использовать Версию Нормальной Формы (vnf). Здесь - это ответ, который я дал для аккуратного способа отслеживать все изменения в определенных полях определенных таблиц.

Статическая таблица содержит статические данные, такие как PK и другие атрибуты, которые не меняются в течение срока службы объекта, или такие изменения не нужно отслеживать.

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

Ссылка выше также содержит ссылку на документ, который содержит гораздо более подробную информацию, включая запросы для получения текущей версии или «оглядывания назад» на любую нужную вам версию.

0 голосов
/ 03 мая 2018

Почему вы не собираетесь использовать SCD-2 (медленно изменяющееся измерение), которое является правилом / методологией для описания наилучшего решения вашей проблемы. Вот преимущество и пример использования SCD-2, и он создает стандартный шаблон проектирования для базы данных.

Тип 2 - Создание новой дополнительной записи. В этой методологии вся история изменений измерений хранится в базе данных. Вы фиксируете изменение атрибута, добавляя новую строку с новым суррогатным ключом в таблицу измерений. И предыдущие, и новые строки содержат в качестве атрибутов естественный ключ (или другие долговременные идентификаторы). Также в этом методе используются столбцы «дата вступления в силу» и «текущий индикатор». Может быть только одна запись с текущим индикатором, установленным на «Y». Для столбцов «дата вступления в силу», то есть start_date и end_date, end_date для текущей записи обычно устанавливается в значение 9999-12-31. Внесение изменений в размерную модель в типе 2 может быть очень дорогой операцией с базой данных, поэтому не рекомендуется использовать ее в измерениях, где в будущем может быть добавлен новый атрибут.

id | amount | start_date    |end_date       |current_flag
1    100      01-Apr-2018    02-Apr-2018     N
2    80       04-Apr-2018    NULL            Y

Подробное объяснение ::::

Здесь все, что вам нужно, чтобы добавить 3 дополнительных столбца, START_DATE, END_DATE, CURRENT_FLAG , чтобы правильно отслеживать вашу запись. Когда в первый раз вставляется запись @ source, в этой таблице будет храниться значение как:

id | amount | start_date    |end_date       |current_flag
1    100      01-Apr-2018    NULL            Y

И, когда та же запись будет обновлена, вы должны обновить «END_DATE» предыдущей записи как current_system_date и «CURRENT_FLAG» как «N», и вставить вторую запись, как показано ниже. Таким образом, вы можете отслеживать все о ваших записях. как показано ниже ...

id | amount | start_date    |end_date       |current_flag
1    100      01-Apr-2018    02-Apr-2018     N
2    80       04-Apr-2018    NULL            Y
0 голосов
/ 01 мая 2018

Я бы предложил новую таблицу, в которой хранится unique id для элемента. Это служит справочной таблицей для всех доступных предметов.

пункт Таблица:

id(int)
1000

Для таблицы, в которой хранятся все изменения для item, назовем ее item_changes таблицей. item_id - это таблица FOREIGN KEY до item id. Отношение между item таблицей и item_changes таблицей составляет one-to-many отношение.

item_changes Таблица:

id(int) | item_id(int)   | version(int) | amount(decimal) | change_reason 
 1      | 1000           |  1           | 100             | NULL
 2      | 1000           |  2           | 20              | correction

При этом item_id никогда не будет NULL, поскольку это действительная таблица от FOREIGN KEY до item.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...