Дублирование данных в базе данных в сравнении с дизайном приложения

Question

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

Допустим, у меня есть приложение, в котором я использую некоторые объекты. У нас есть Заказ, содержащий информацию о клиенте, сроках и т. Д. Затем у нас есть Служба, имеющая отношение один-ко-многим с Заказом. Сервис содержит его имя. Кроме того, у нас есть сущность "Правило", которая устанавливает некоторые правила относительно того, что вычитать из материального запаса. Он имеет отношение один ко многим с объектом службы.

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

Обычно, как бы я справился с этим, было бы дублировать Сервисы и Правила и вставлять их в новую таблицу, чтобы данные были независимы от той, которая используется во время генерации Заказа. Порядок будет просто указывать на дублированные данные вместо оригинальных, что решит мою проблему. Но это дублирование данных, и, как мне кажется, это не лучший способ сделать это.

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

Answer 1

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

Answer 2

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

Идея состоит в том, чтобы рассматривать каждую сущность, для которой требуется управление версиями, как объект и хранить в экземплярах объекта базы данных. Скажем, для service Сущность это может быть представлено как:

1. service таблица, содержащая только service_id столбец, PrimaryKey;
2. service_state (или же ..._instance) таблица, которая содержит:
   • service_idВнешний ключ к service.service_id;
   • state_start_dtмомент, когда это состояние становится активным, NOT NULL;
   • state_end_dt, момент времени, когда это состояние устарело, NULLсостояние;
   • все реальные атрибуты service;
   • Первичный ключ service_id + state_start_dt,
3. наверняка, state_start_dt::state_end_dt диапазоны не могут перекрываться, должны быть ограничены.

Что хорошего в таком подходе?

1. У вас есть полная история изменений состояния ваших основных объектов;
2. Вы можете запросить систему, как это было в данный момент времени;
3. Доставка новой конфигурации может быть сделана заранее, вставив соответствующую запись (записи) с желаемым state_start_dt Марки;
4. Аудит изменений интегрирован в проект (для полной трассировки требуется пара дополнительных столбцов).

В чем дело?

1. Там будет дублирование данных. Чтобы уменьшить его, обязательно разбейте инстанцирующие отношения. Как: не создавайте единую таблицу для данных о клиентах, создавайте кучу таблиц для учетных данных, адресов, контактов, финансовой информации и т. Д.
2. Настоящий первичный ключ service.service_idв то время как информация хранится в подчиненной таблице service_state, Это может привести к ситуации, когда ваш service существует, в то время как кто-то (намеренно или по ошибке) удалил все service_state записей.
3. Трудно решить, в какой момент времени это безопасно удалить state записи в автономный архив, если в системе есть объекты, ссылающиеся на serviceнеобходимо проверить их даты вступления в силу до удаления каких-либо state записей.
4. Из-за #3, нельзя просто удалить записи из service_state, На самом деле, это также неправильно полагаться на state_end_dt столбец, для службы, возможно, был активен некоторое время, а затем подавлен. И запрос сервиса в момент, когда он был активным, должен указывать сервис как активный. Следовательно, status колонка обязательна.

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