Список изменений для таблицы

Question

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

Идея 1

Моя первая идея состояла в том, чтобы создать 2 таблицы. Один из них содержит все рестораны RESTAURANT_VALUE(restaurantId*, restaurantValueId*, address, phone, ..., username, insertDate). Каждый раз, когда происходит изменение, создается новая запись. Затем следует таблица RESTAURANT (restaurantId*, restaurantValueId), которая будет ссылаться на действующий restaurantValueId. Таким образом, одна таблица содержит текущую и предыдущую версию.

Идея 2

Она начинается с 2-мя столами, а также. Один из них содержит все текущие рестораны. например RESTAURANT_CURRENT. И вторая таблица, содержащая все изменения RESTAURANT_HISTORY. Поэтому оба должны иметь одинаковые столбцы. Каждый раз, когда происходит изменение, значения «текущей» таблицы копируются в таблицу предыстории, а новая версия - в «текущий».

Мое мнение

Идея 1 не волнует, если столбцы всегда будут добавлены или нет, поэтому техническое обслуживание и добавление столбцов будет легко. Однако, по-моему, по мере роста базы данных ... не замедлит ли она? Идея 2 имеет то преимущество, что таблица со значениями никогда не будет иметь никакого «старого» материала и не будет переполнена.

Теоретически я думаю, что идея 1 должен быть один сделано

Что вы думаете. Вы идете на Идею 1 или другую? Есть ли другие важные практические мысли, о которых я не знаю?

Answer 1

Этот подход сильно зависит от ваших потребностей. Зачем вам нужна таблица истории?

Если это просто для целей аудита, сделайте отдельный стол restaurant_history (идея 2), чтобы сохранить историю в стороне. Если вы хотите, чтобы представить историю в приложении, а затем пойти на signle restaurants таблицы с одним из следующих вариантов:

• seq_no - запись номера версии увеличивающийся с каждым обновлением. Если вам нужны текущие данные, вы должны искать самый высокий seq_no для данного restaurant_id(s), поэтому при необходимости использовать также current маркер, позволяющий straighforward current = true
• valid_from, valid_to - где valid_to является NULL для текущей записи

Иногда возникает необходимость эффективно запрашивать, какие атрибуты точно изменились. Чтобы сделать это, вы можете рассмотреть таблицу истории на уровне атрибута: (restaurant_id, attribute, old_value, new_value, change_date, user).