Перемещение объекта базы данных в другую схему
При перемещении объекта базы данных в другую схему можно воспользоваться рефакторингом базы данных, чтобы проще и точнее обновить все ссылки на этот объект в проекте базы данных. Например, можно поделить базу данных на несколько схем, чтобы повысить безопасность или обеспечить более логичное упорядочение. После такого разделения нужно не только переместить в новую схему один или несколько объектов, но и обновить все полные ссылки на эти объекты. При ручном изменении всех ссылок, которые должны указывать на новую схему, можно допустить ошибки. С помощью рефакторинга базы данных эти ссылки можно найти и обновить автоматически.
Сохранение намерений с помощью журнала рефакторинга
При перемещении объекта базы данных в другую схему для проекта базы данных добавляется запись в журнал рефакторинга. Этот журнал помогает при развертывании изменений убедиться, что соответствующий объект в целевой среде переименован так, как намеревался разработчик. В противном случае существующий объект будет удален, а вместо него будет добавлен объект с новым именем. Журнал сохраняется в XML-файле с именем Имя_проекта.refactorlog. Этот файл нужно вернуть в систему управления версиями вместе с остальными файлами, образующими проект базы данных. В файле Имя_проекта.refactorlog содержатся только сведения об операциях рефакторинга, для которых требуются особые действия во время развертывания.
Развертывание
При использовании рефакторинга выполняется обновление только проекта базы данных, а не рабочей базы данных. Следуя этой стратегии, можно воспользоваться всеми преимуществами проектов базы данных, включая управление версиями и командную разработку. При развертывании изменений с помощью журнала рефакторинга можно сохранить назначение изменений в проекте базы данных. Например, вместо операций DROP и ADD может быть выполнено переименование.
Дополнительные сведения см. в разделе Построение и развертывание баз данных в изолированной среде разработки.
Примечание
В среде на основе рабочих групп приложения и модульные тесты базы данных следует выполнять до развертывания изменений на рабочем сервере.Дополнительные сведения см. в разделе Начало командной разработки базы данных.
Общие задачи
В таблице приведено описание стандартных задач, которые могут оказаться полезными при реализации этого сценария, и ссылки на более подробные сведения о выполнении этих задач.
Задача |
Справочные разделы |
|---|---|
Получение практического опыта. Возможность подробнее ознакомиться с перемещением объектов базы данных в другую схему, в дополнение к другим типам рефакторинга, следуя указаниям в пошаговом руководстве. |
Пошаговое руководство. Применение методов рефакторинга базы данных |
Перемещение объекта базы данных в другую схему. С помощью рефакторинга можно переместить объект базы данных в другую схему и автоматически обновить все ссылки на этот объект в проекте базы данных. В ходе операции рефакторинга можно просмотреть изменения перед их применением. |
Практическое руководство. Перемещение объекта базы данных в другую схему |
Отмена операции рефакторинга. Если необходимо отменить операцию рефакторинга, это можно сделать в текущем сеансе Visual Studio. |
Практическое руководство. Отмена операции рефакторинга базы данных |
Развертывание изменений, связанных с рефакторингом базы данных. После выполнения рефакторинга проекта базы данных необходимо развернуть эти изменения в целевой базе данных. Обычно изменения развертываются в изолированной среде разработки, чтобы их можно было проверить перед возвратом в систему управления версиями. |
Практическое руководство. Развертывание изменений оптимизации кода базы данных |
Устранение неполадок: подробная информация об устранении типичных неполадок, связанных с рефакторингом баз данных. |
Связанные сценарии
Переименование всех ссылок на объект базы данных
Переименование ссылок на сервер или базу данных
Полные имена объектов базы данных
Расширение набора подстановочных знаков в инструкциях SELECT