Хорошо, я отвечу на свой вопрос.
Я добавил все наши объекты SQL в их собственные файлы .sql в проекте Visual Studio .dbproj.Однако незначительные синтаксические несовместимости между Sybase-версией RAISERROR и Microsoft-версией RAISERROR привели к тому, что код проверки, встроенный в Visual Studio, стал недоволен.Проблема с проектом базы данных заключалась в том, что это на самом деле вызвало ошибку компиляции, которая в основном превратила его в show-stopper.
Так что я отказался от этой идеи и добавил файлы .sql в стандартный файл проекта .csproj.Затем я реализовал некоторый пользовательский код, который загружал бы все файлы .sql и объединял их в сценарий развертывания при вызове.Я добавил вызов к пользовательскому коду в пост-сборку файла .csproj, чтобы всякий раз, когда он компилировался, он выводил сценарий развертывания - который работает как сон с нашим сервером сборки.
Для того, чтобыЧтобы получить некоторые из преимуществ .dbproj, я изучал написание полного синтаксического анализатора SQL, но некоторые сообщения о SO быстро обескуражили.Вместо этого я выполнил некоторый рудиментарный анализ с помощью regex, что дало мне несколько интересных функций без особых усилий:
- Код может обнаруживать зависимости между различными файлами .sql и добавлять их в сценарий развертывания.в правильном порядке, чтобы избежать системных предупреждений.
- Там, где не было никаких зависимостей, объекты были упорядочены на основе типа объекта (хранимая процедура, функция, оператор предоставления и т. Д.), А затем по имени, чтобы результирующий сценарий всегда был упорядочен одинаково - что очень важноесли вам нужно использовать две версии сценария.
- Сценарий развертывания может определить некоторые необходимые разрешения, поэтому мне не нужно отслеживать все операторы GRANT.
- Хранимые процедуры, которые находятся в базе данных, но не в сценарии, могут автоматически удаляться - поэтому мне не нужно отслеживать, в каком состоянии находится каждая база данных - мы просто запускаем сценарий, и все находится в правильном состоянии.
- У нас есть несколько хранимых процедур, которые вызывают наши автоматические тесты, которые не следует развертывать.Код может обнаружить их и включить в сборку Debug и исключить их в сборке выпуска.
- Пользовательский код также генерирует сценарий diff, который определяет, какие изменения внесет сценарий развертывания в базу данных, и распечатывает их,Это позволяет человеку, который запускает сценарий, получить представление о том, что он будет делать.Например, скрипт diff может сказать им, что не будет внесено никаких изменений - поэтому им вообще не нужно запускать скрипт развертывания - что довольно удобно, если он спасает их при входе в систему в 3 часа ночи, чтобы перевести базу данных в автономный режим и перевести ее в автономный режим.резервные копии и т. д.
Таким образом, конечный результат заключается в том, что все мои объекты SQL находятся в отдельных файлах, что упрощает их работу в Visual Studio и управление из-под контроля исходного кода.Впервые с тех пор, как я начал эту работу, я могу посмотреть историю в управлении исходным кодом и сказать, какие файлы были изменены (до этого у нас был один огромный файл .sql, в котором было абсолютно все).