Безопасно ли удалять и затем создавать ограничения в базе данных

Question

Я немного растерялся и мне нужна ваша помощь. У меня есть база данных, которая имеет более 150 таблиц. У меня есть несколько полей, которые должны поддерживать Unicode, но сейчас они этого не делают, и поэтому я хочу изменить тип данных столбца на ntext и nvarchar, в этом процессе я должен удалить ограничения и затем создать их снова. Безопасно ли отбрасывать ограничения и создавать их снова.

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

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

Answer 1

Но есть и лучший способ: Вы можете отключить индекс. См. Msdn . Это сохраняет определение индекса.

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

Редактировать: (после комментария gbn)

Отключение, скорее всего, не работает для вашего случая.

Мы также снимаем ограничения при обновлении базы данных, и в целом это сохранение. Другие аспекты уже упоминались другими: вам нужно знать их все, чтобы создать их. Существуют инструменты, которые создают сценарии из существующих баз данных, или вы можете написать это самостоятельно. Вся информация должна фактически находиться в базе данных. Например, вы получаете сценарии от студии управления, но только один за другим (насколько я знаю).

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

Answer 2

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

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

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

Подход сторонних инструментов использует транзакцию блокирует объекты на время всех изменений.

Конечно, вы можете делать по одному, а не большой взрыв, но эти инструменты все еще полезны.

Answer 3

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

Полагаю, я просто говорю, убедитесь, что у вас есть четкий процесс, и что вы следуете ему.

Answer 4

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

Answer 5

мы постоянно меняем схему, вот наша процедура в целом:

для каждой таблицы:

• внеся изменения в SQL Server Management Studio, вы заметите, что эти сценарии сбрасывают и воссоздают ограничения все время без проблем

• сгенерируйте скрипты, скопируйте их в файл

• отменить изменения (не применять их к базе данных)

перейдите в базу данных тестирования / разработки с той же схемой, что и в рабочей среде, и запустите свой скрипт

если у вас есть какие-либо ошибки, устраните их, восстановите тест / разработку и повторите тест

если у вас нет ошибок

• при необходимости создайте резервную копию

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

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

• запустить файл скрипта

• вывод базы данных из однопользовательского режима