Контроль версий для нескольких частей связанных данных

Question

Я пытаюсь выяснить, как лучше хранить информацию о ревизиях / истории для ревизий в нескольких строках данных, на случай, если по какой-то причине нам нужно вернуться к этим данным.

Это общий вид макета:

item
---------------
id
title
etc...

region
---------------
id
title
etc...

release_type
-----------------
id
title
etc...

items_released_dates_data
---------------------
item_id
region_id
release_type_id (these three form the primary key)
date

Таким образом, вы можете иметь одну дату выпуска для каждого элемента + region_id + release_type, и мы в основном отслеживаем только дату (Для целей этого вопроса«date» может быть числом, строкой и т. д. Я обязательно столкнусь с этой проблемой снова)

Изменения представляются в большом количестве, когда новые данные добавляются все в items_released_dates_data, где item_id = your_idсначала удаляется, а затем оператор вставки добавляет новые значения (возможно, это не лучший способ сделать это?)

Я думал создать такую ​​таблицу:

items_release_dates_data_history
-------------------------------------
item_id
timestamp
description
raw_data

Созданиеописание - краткое резюме того, что было обновлено, и включая данные в некотором формате, таком как json или xml или что-то, что может быть быстро декодировано на стороне клиента, чтобы дать пользователю обзор изменений и выбор, чтобы пересмотреть к данной версии.Тогда каждая запись в items_released_dates_data также требует записи в items_released_dates_data_history (не похоже на вопрос, не так ли ?: |)

Я читал кое-что о триггерах mysql, которые были бы полезны здесь, но, честно говоря, я неЯ ничего не знаю о них, поэтому я работаю с тем, что я понимаю.

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

Answer 1

Я второй комментарий Алекса Миллера. Пока все, что ты пишешь, имеет смысл.

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

Также рассмотрите механизм хранения архива вместо MyISAM или InnoDB для таких таблиц - они созданы для такой работы.

Кроме того, поисковая фраза, которую вы, вероятно, ищете, - «контрольный журнал».

Answer 2

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

Что касается удаления + вставки, то это нормально, если вы не используетене заканчиваются слишком большим трафиком, поскольку оба являются блокирующими действиями.При вставке или удалении строки для обновления индекса используется много времени.Если вы используете таблицу MyISAM, она также остановит все чтения таблицы, пока эти действия не будут завершены.Обновление будет так же, но в течение гораздо более короткого времени.InnoDB будет блокировать только строку, так что это не проблема.