Реализация отката данных в существующем приложении CRUD

Question

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

Скажите, что у меня есть имя, фамилия и номер социального страхования на странице в этом приложении. Пользователь А обновляет поле Фамилия. Позже, пользователь B замечает, что новая фамилия отличается, и хочет узнать, кто ее изменил, и откатить ее, если необходимо.

Я не знаком с этим, поэтому, если я пропускаю или неправильно использую некоторые термины, прости меня.

Это приложение имеет бэкэнд MS SQL, а DAL - это в основном SPROCS. Прямо сейчас нет никаких архивов или гробниц, о которых можно было бы говорить.

Я думал просто создать таблицу для каждой существующей таблицы с именем tblPerson -> tblPersonTombstone, и тогда часть отката будет считываться из этой таблицы. К сожалению, первоначальные дизайнеры БД разработали его таким образом, чтобы одна страница в приложении могла содержать информацию из 2 или 3 разных таблиц. Таким образом, я думаю, мне нужен более транзакционный подход.

Любое направление или указатели будут с благодарностью. Я на правильном пути со своими мыслями? Может быть, я слишком усложняю это? Как это сделали другие?

Я вижу этот пост Как реализовать операцию отмены в приложении Windows .net , а также этот Новый проект CodePlex: простая структура Undo / Redo , но я зачтен это не соответствует моей реальной ситуации. Я не хочу, чтобы пользователи нажимали ctl + z. Мне нужно позволить им откатить всю страницу обратно в предыдущее состояние. Если я неправильно понимаю использование этих двух примеров, скажите, пожалуйста.

Спасибо за время.

Answer 1

То, о чем вы говорите, относится к теме аудита. К сожалению, это одна из наиболее сложных реализаций.

Вот лучшая практика:

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

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

Большинство людей используют триггеры для заполнения этих записей ревизий.

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

Так что большинство людей так и делают.

Вот еще один способ:

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

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

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

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

Ссылки

Вот ссылка на stackoverflow, где они говорят о реализации аудита в SQL Server, некоторые люди упоминают Change Data Capture, который является новым в SQL 2008 Enterprise ... Он не выполняет откат автоматически, но он сохраняет данные аудита:

Предложения по внедрению таблиц аудита в SQL Server?

Answer 2

2 мысли:

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

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