Теория архивирования

Question

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

У меня есть идея, как это сделать, но я не уверен, что это лучший подход: иметь дубликат каждой таблицы, которая будет "архивировать" все, а затем при помещении элемента в архив все Отношения FK / PK будут обновлены, хотя это кажется громоздким процессом.

Другая идея, которая у меня была, заключалась в том, что каждому элементу (то есть контакту) будет назначаться PK, а затем для каждого элемента будет вторичный ключ, который затем будет связан с каждым проектом. Основная проблема в этом заключается в том, что если контакт обновляется в реальном проекте, потребуется много обновлений.

Пожалуйста, дайте мне знать, если у вас есть какие-либо вопросы.

Спасибо за помощь.

Answer 1

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

Есть несколько способов сделать это, каждый со своими плюсами и минусами, и способ, которым вы выберете, будет зависеть от того, что вам нужно сделать с временным элементом ваших данных. Вот некоторые из них:

1. Аудиторский след
   • Вы отслеживаете изменения, внесенные в запись с течением времени, и основная запись отражает ее текущее состояние
   • Уменьшает дублирование данных до минимума
   • Скорее всего, не подходит для модели "снимок", которую вы ищете легко
2. Самый актуальный
   • У вас есть запись для каждой «версии» сущности с отметкой времени, когда она была создана
   • Позволяет легко вернуться к моменту времени
   • Позволяет легко "раскошелиться" на сущность
   • имеет наибольшее дублирование данных

Мартин Фаулер написал несколько статей, относящихся к проектированию моделей, которые работают с временными данными, поэтому я хотел бы начать с хорошего и прочного обоснования этой темы.

Answer 2

Хм ... Единственный раз, когда я столкнулся с чем-то вроде этого, была идея решить это на прикладном уровне, а не на БД.

Например, для ruby, вы можетеиспользуйте vestal_versions или paper-trail.

Paper-trail, например, сохраняет версии всех объектов как сериализованные объекты в одной таблице и работает с дельтами.