управление версиями каждого поля по сравнению с полем даты истории?

#mysql #sql #database #database-design

#mysql #sql #База данных #база данных-дизайн

Вопрос:

Что вы рекомендуете и почему?

У меня есть несколько таблиц, когда я вношу изменения в данные … они должны перейти в таблицу истории (аудит) с датой вступления в силу.

Другим решением является управление версиями каждого поля для вставки новой строки при внесении изменений в данные?

Какой метод является лучшим для получения информации о счете? Название товара и цена всегда меняются

Ответ №1:

Это медленно изменяющиеся размеры, type 2 и type 4 соответствующим образом.

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

В принципе, type 2 (управление версиями) более подходит, когда вам нужно запрашивать исторические значения так же часто, как и текущее, в то время как type 4 (таблица истории) больше подходит, когда вы чаще запрашиваете текущее значение и есть больше запросов (я имею в виду больше запросов для разработки) к самому последнему значению.

1. У меня есть order_items для отображения прошлых заказов.. какой из них лучше? Значение названия товара и цены всегда меняется.

2. @user: обычно (обычно) таблица истории лучше, поскольку вам важнее текущая цена и вы выполняете к ней больше запросов. Таким образом, вам не нужно будет добавлять фильтр для isActive или аналогичное поле к каждому запросу.

3. Вместо ДАТЫ в таблице истории я добавил поле версии. Пример таблиц: item.version, item_history.version и таблица order_table будут содержать номер версии. Таким образом, я получу 100% точную информацию, а не буду ретранслировать при поиске по дате.

Ответ №2:

Система, которую мы используем и которой довольны:
Для каждой таблицы, требующей истории, мы создаем аналогичную таблицу и добавляем поле метки времени в конце, которое становится частью PK.
Каждое обновление исходной таблицы мы вставляем в таблицу истории с теми же условиями:

 update table x WHERE somthing something

insert into table x_history 
select * from x WHERE something something

Это обеспечивает чистоту ваших данных и стройность таблиц.

1. В этом решении нет проблем с точностью? Например.. Отображение данных счета из таблицы истории (старые данные).. Я надеюсь, что это показывает правильную цену, лол

2. Почему должна быть проблема? Вы можете использовать управление версиями, но оно требует больше логики / кода, который я считаю ненужным

Ответ №3:

Моим личным предпочтением было бы использовать шаблон Observer в вашем приложении и реализовать отдельную таблицу истории. Это означает, что вы можете извлекать данные из таблицы истории, когда вам это нужно, и вы не ставите под угрозу скорость запроса к основной таблице.