Самый быстрый способ отката данных SQL: Лучший способ разработки хранимой процедуры обработки данных

Question

Редактировать: ОК. Я задал неправильный вопрос здесь.

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

---

Старый вопрос: У меня есть база данных разработки, содержащая живые данные. Это должно быть скрыто для конфиденциальности, особенно названия компаний и контактные данные.

Чтобы бросить гаечный ключ в работах, компания NAME является первичным ключом. (.... Да, я знаю. Унаследованный код. Ура.)

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

Итак, процесс будет:

• Данные компании Mangle
• проверка в приложении, чтобы убедиться, что связанные данные отображаются правильно
• откат данных для исправлений повторить

Моя первоначальная мысль - просто выполнять резервное копирование и восстановление после каждого теста. Но это кажется трудоемким. Есть ли лучший способ?

Answer 1

Если вы проводите какие-либо тесты данных, рассмотрите возможность использования тестовой базы данных или базы данных игровой площадки для этого ...

Если это невозможно ... Приведенный ниже код откатит все изменения данных ...

BEGIN TRANSACTION
--do my tests
ROLLBACK

EDIT
Вы также можете добавить код в свое приложение, которое будет выполнять тесты, а затем восстанавливать резервную копию после завершения теста.

Answer 2

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

За исключением этого резервного копирования и восстановления, вероятно, ваш лучший выбор.

Answer 3

ИМХО искажение данных внутри вашей базы данных сделает немного больше, чем испортит вашу базу данных. Если любопытные глаза получили доступ к вашей базе данных, я боюсь, что в худшем случае у вас будут большие проблемы, и в лучшем случае они поймут, как устранить искажение. В конце концов, они гипотетически получили доступ к вашей базе данных. Лёгкая часть будет обратить вспять некоторую запутанность.

Answer 4

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

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

Answer 5

Опции, которые я обнаружил до сих пор:

Мастер публикации баз данных Microsoft SQL Server 1.1 для MS SQL 2005

http://www.microsoft.com/downloads/details.aspx?FamilyId=56E5B1C5-BF17-42E0-A410-371A838E570A&displaylang=en

(ограничение по одной гиперссылке)