Блог

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

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

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

Я подумал о двух сценариях хранения данных:

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

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

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

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

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

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

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

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

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

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

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

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

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