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

Question

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

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

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

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

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

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

Я вижу этот пост How to implement ‘undo’ operation in .net windows application?, а также этот New CodePlex project: a simple Undo/Redo framework, но я убежден, что ни одна из них не соответствует моей реальной ситуации. Я не хочу, чтобы пользователи нажимали ctl + z. Мне нужно, чтобы они перевернули всю страницу назад в предыдущее состояние. Если я неправильно понимаю использование этих двух примеров, то, пожалуйста, скажите это.

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

Answer 1

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

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

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

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

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

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

Таким образом, большинство людей это делает.

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

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

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

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

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

Ссылки

Вот ссылка на StackOverflow, где они говорят о реализации аудита в SQL Server, некоторые люди упоминают Захват измененных данных, который является новым в SQL 2008 Enterprise ... Это не делает откаты автоматически , но это не магазин аудита данные:

Suggestions for implementing audit tables in SQL Server?

Answer 2

2 мысли:

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

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