Db дизайн для утверждения обновления данных

Question

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

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

Я предполагаю, что наборы обновлений данных будут сгруппированы в «представление данных», и данные будут повторно проверены и исправлены / отклонены / утверждены, когда кто-то будет контролировать качество представления.

Я думал о двух сценариях, касающихся хранения данных:

1) Сохранение ожидающих данных о состоянии в той же таблице, что и текущие данные, но добавление флага для указания его статуса. Я мог видеть здесь проблемы с необходимостью удаления ограничений или обнуления обязательных полей для поддержки «неполных» данных статуса. Тогда возникает проблема с обработкой обновления существующих данных, вам нужно будет добавить новую строку для обновления и связать ее с существующей «живой» строкой. Это кажется мне немного грязным.

2) Добавьте новые таблицы, которые отражают действующие таблицы, и сохраняйте там данные до тех пор, пока они не будут утверждены. Это позволило бы мне сохранить полный контроль над существующими живыми таблицами, в то время как над «ожидающими» таблицами можно злоупотреблять тем, что, по мнению пользователя, он хочет поместить туда. Недостатком этого является то, что я получу много дополнительных таблиц / SP в БД. Еще одна проблема, о которой я думал, заключалась в том, как пользователь мог связать две записи, при этом связанная запись могла бы быть записью в оперативной таблице или записью в таблице ожидания, но я полагаю, что в этой ситуации вы всегда можете взять копию связанную запись и рассматривать ее как обновление?

Ни одно из решений не кажется идеальным, но второе мне кажется лучшим вариантом - есть ли третье решение?

Answer 1

Ваш вариант 2 очень похож на лучшую идею.Если вы хотите использовать ссылочную целостность и все приятные вещи, которые вы получаете с СУБД, вы не можете иметь ожидающие данные в одной таблице.Но нет необходимости в том, чтобы неструктурированные данные находились в ожидании, когда данные все еще структурированы, и, вероятно, вы хотите, чтобы БД играл свою роль в обеспечении соблюдения правил даже для этих данных.Даже если вы этого не сделали, ожидающие данные хорошо вписываются в стандартную структуру таблиц.

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

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

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

Answer 2

«Единица работы» - хорошее название для «передачи данных».

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

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

Answer 3

Первый scenerio кажется хорошим.Столбец «Добавить статус» в таблице. Нет необходимости удалять ограничение Nullable, просто добавьте одну функцию, чтобы проверить обязательные поля, основанные на флаге, например, если флаг имеет значение 1 (неполное), в противном случае допускается пустое значение.Что касается второго сомнения, вы хотите добавить данные или обновить все данные.

Answer 4

Я думаю, что второй вариант лучше.Чтобы управлять этим, вы можете использовать View, который будет содержать обе таблицы, и вы можете работать с этой структурой через view.

---

Другой хороший подход - использовать столбец XML в отдельной таблице для хранения необходимых данных (неизвестного количества / названия столбцов).Вы можете создать только одну таблицу с рекламным столбцом XML. Тип столбца определяет, к какой таблице относится этот документ.