Как настроить среду разработки для хранимых процедур SQL Server?

Question

Я недавно начал работать над унаследованным приложением, которое имеет большую часть своей бизнес-логики в хранимых процедурах, распределенных по двум или трем базам данных SQL Server. В настоящее время весь код также редактируется в реальной среде.

Поскольку я новичок в кодовой базе, я действительно не хочу вносить какие-либо изменения в живую среду, и поэтому я пытаюсь настроить среду разработки. Мы используем Visual Studio для создания сценариев всех объектов базы данных и отслеживаем их в Subversion. После этого я могу настроить экземпляр dev SQL Server для работы, но одна проблема заключается в том, что код полон жестко закодированных ссылок на имена серверов и баз данных, например, многие из сохраненных процедур выглядят примерно так:

CREATE PROCEDURE server1.db1.dbo.proc1 AS

INSERT INTO db1.dbo.table1
EXEC server2.db2.dbo.proc2

END

Как я могу безопасно изменить все эти ссылки? До сих пор я думал о двух вариантах:

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

2) Установите псевдоним dns на моем локальном ящике, отредактировав файл \ windows \ system32 \ drivers \ etc \ hosts, который перенаправляет server1 и server2 на экземпляры баз данных. На производственных серверах они будут затем указывать на производственные базы данных.

Какая из них, по вашему мнению, является лучшей настройкой? Видите ли вы какие-либо риски, с которыми я пренебрегал и которые следует принимать во внимание?

Answer 1

Если все ссылки относятся к связанному серверу «Server2» и т. Д., То вы можете указать другой базовый SQL Server в своем устройстве dev для этого связанного сервера

Вы можете сделать одно из:

• Использовать sp_setnetname после создания
• Установить @datasrc sp_addlinkedserver во время создания. отделяет имя связанного сервера от фактического имени сервера

Answer 2

Правильное решение, по-видимому, состоит в том, чтобы удалить все жестко закодированные ссылки на рабочий сервер, если это возможно (ваше решение 1).Необычно делить базу данных сервера между производственной и рабочей средой (если это не отдельная база данных, хранящая, например, только статические / справочные данные).Сервер нужен вам только в том случае, если вы выполняете работу на нескольких серверах. Согласно GBN, вы можете добавить sp_addlinkedserver

. Путь псевдонима DNS опасен.Если что-то не получится, вы будете обновлять производственные данные из вашей среды разработки.

Примечание: если у вас есть доступ к инструменту, такому как Visual Studio DBPro, вы также можете использовать переменные для токенизации ваших скриптов, например, ссылкитаблица, такая как $ (SERVER). $ (DATABASE) .dbo.Table При развертывании проекта подставляются соответствующие значения среды.