Отслеживание изменений и обработка ожидающих утверждений в SQL

#sql #tsql #sql-server-2008 #data-structures

#sql #tsql #sql-server-2008 #структуры данных

Вопрос:

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

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

Я попытался найти решение и в итоге получил возможные решения — вести записи об изменениях в новой таблице (RequestID, RequestDate, requesttype, request (store asp.net datatable как xml)) — дублируйте запись current_row как new_row и добавьте столбец RequestID в эту таблицу (это может значительно увеличить размер этой исходной таблицы) — дублируйте структуру исходной таблицы, где мы будем хранить только ожидающий запрос (это также может привести к многочисленным таблицам, в зависимости от разных типов запросов и количества исходных таблиц)

Был бы признателен за любые комментарии относительно моих идей.

Ответ №1:

Что вам нужно, кроме добавления столбца статуса со значениями ожидающий / одобренный?

Комментарии:

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

Ответ №2:

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

  2. Реализация разделения. Взгляните на эту статью для получения дополнительной информации о разделении

Комментарии:

1. 1. Использование новых таблиц может быть проблемой, потому что я, возможно, захочу сохранить старые / значения в информации запроса. Выбор опции new table может привести к большому количеству ненужной работы. Как насчет возможных изменений исходной структуры таблицы? 2. реализация разделения?

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

3. Что такое реализация разделения?