Как управлять тестовой базой данных в SQL Server

Question

В настоящее время я работаю над приложением, которое использует базу данных SQL Server 2008, которая находится внутри локальной сети. У меня две проблемы, связанные с управлением базой данных:

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

2. Я выполняю значительную часть своей работы удаленно, поэтому я установил SQL Server 2008 Express на свой ноутбук и локально запускаю третью копию базы данных. Это лучший вариант для удаленной работы? Решение, которое я искал в этой ситуации, состоит в том, чтобы представить мою тестовую базу данных в Интернете ограниченному пользователю, которого я мог бы использовать для удаленной разработки. Это возможно / рекомендуется?

Answer 1

Вероятно, самый чистый и повторяемый способ - использовать реальный процесс сборки для кода и объектов вашей базы данных.Сначала поместите весь код вашей базы данных и объекты в систему контроля версий.Затем используйте DBGHOST для создания сценариев обновления, чтобы обновить вашу производственную базу данных.В рамках этого вы можете создать выходные данные, которые создадут пустую базу данных разработчиков, которая будет легко соответствовать любому данному выпуску при использовании DBGhost.Мы используем уже около 3 лет и иначе не будем.Проверьте там сайт для полной прогулки по.Хорошо стоит денег.Я сказал, что это стоит денег?

http://www.innovartis.co.uk/

Answer 2

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

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

Что касается обновления производственных / тестовых баз данных; Я всегда генерирую сценарии изменений, когда меняю сервер разработки, а затем сохраняю их организованными, чтобы их можно было применить к тестовым, а затем и к последующим рабочим серверам. Вы можете создать эти сценарии через SQL Server Management Studio или Visual Studio.