В этой статье я хотел бы рассказать о наборе полезных дополнений к Visual Studio, которые могут значительно облегчить разработку баз данных на базе MS SQL Server. В качестве основных преимуществ использования SSDT я бы выделил следующие:
- возможность легкого изменения (рефакторинга) схемы базы данных (вы можете переименовать столбец таблицы, и все представления, функции и хранимые процедуры, ссылающиеся на него, будут автоматически исправлены с учетом изменений)
- создание модульных тестов для базы данных
- сохранение структуры базы данных в системе контроля версий
- сравнение схемы/данных с возможностью генерации скрипта для приведения схемы/данных в необходимое состояние
Если вас интересует, как воспользоваться этими и другими преимуществами, обратитесь к кат.
Установка и первое знакомство
Все необходимое для установки можно найти на сайте страница загрузки в Центре разработчиков данных.Выбрав нужную версию, вы легко сможете установить инструменты на свой компьютер и описывать это я не вижу смысла.
После установки в окне создания нового проекта появится новый тип проекта:
После создания нового проекта вы увидите следующее:
На панели «Обозреватель объектов SQL Server» (меню «Вид» -> «Обозреватель объектов SQL Server») мы видим нечто очень похожее на обозреватель объектов в SQL Server Management Studio, при этом удалено все, что не особо полезно на этапе разработки базы данных.
Подключившись к существующей базе данных, вы можете развивать базу данных в так называемом подключенном режиме.
Это мало чем отличается от классического подхода, используемого в SQL Server Management Studio, и не будет обсуждаться в этой статье.
Отключенный режим
Этот режим разработки нам наиболее интересен, потому что.именно он позволяет получить основные преимущества использования SSDT. В основе работы лежит очень простая идея — предоставить разработчикам возможность хранить все скрипты создания объектов базы данных (таблиц, представлений, процедур хранения и т. д.) в проекте особого типа в составе существующего или нового решения.
На основе сценариев Visual Studio может создать файл DACPAC, который по сути представляет собой zip-архив со всеми сценариями t-sql. Имея файл DACPAC, можно будет публиковать его в необходимом экземпляре базы данных, сравнивая схему, описанную в DACPAC, и схему в целевой базе данных.
Во время публикации специальные механизмы производят сравнения, в результате чего автоматически создаются сценарии миграции, позволяющие применить изменения без потери данных.
Чтобы увидеть это в действии, я предлагаю рассмотреть следующие примеры.
Начнем с опции импорта.
Вызовите контекстное меню проекта и увидите 3 возможных варианта:
- Скрипт (*.
sql) – добавляет в структуру проекта один или несколько файлов *.
sql из указанного места;
- Приложение уровня данных (*.
dacpac) – добавляет файлы *.
sql, а также различные настройки базы данных из специального файла DACPAC, описанного выше; может содержать не только схему базы данных, но также данные и различные настройки базы данных;
- База данных… — аналогично предыдущему варианту, но источником данных является существующая база данных
» и импортируем локальную базу данных.
Он содержит одну таблицу и одну хранимую процедуру.
В обозревателе объектов SQL Server исходная база данных выглядит следующим образом:
После завершения импорта мы увидим очень похожую картину, с той лишь разницей, что структура базы данных будет представлена в Solution Explorer в виде файлов *.
sql.
Мы также всегда можем добавить новые элементы, используя диалоговое окно «Добавить новый элемент», в котором перечислены все возможные объекты базы данных:
Добавим таблицу TestTable. Новый файл скрипта TestTable.sql добавим в корень проекта и для удобства переместим его в папку Tables.
Для создания схемы таблицы мы можем использовать как панель дизайнера, так и панель T-SQL. Все изменения, внесенные в одной панели, будут немедленно отражены в другой.
Мы также можем изменить существующие сценарии.
Visual Studio предоставляет для этого удобный и всеми любимый IntelliSense. Поскольку мы не подключены к физической базе данных, Visual Studio анализирует все скрипты в проекте для корректной работы IntelliSence, что позволяет мгновенно отражать последние изменения, внесенные в схему базы данных.
Я хотел бы отметить, что нам не следует беспокоиться о дополнительных изменениях в нашей базе данных.
Вместо этого мы всегда создаем скрипты так, как если бы объекты создавались заново.
При публикации пакета DACPAC сценарии миграции будут созданы автоматически путем сравнения файла DACPAC и схемы в целевой базе данных.
Как уже говорилось, DACPAC содержит не только схему и данные, но и ряд полезных настроек, для просмотра/редактирования которых мы можем использовать окно свойств нашего проекта.
Свойство Целевая платформа позволяет указать версию базы данных, для которой будут проверяться скрипты в проекте.
Минимальная поддерживаемая версия MS SQL Server 2005. Если, например, установить версию базы данных 2005 и попытаться создать столбец типа «География», то при компиляции мы получим следующее сообщение:
На вкладке «Настройки проекта» мы можем установить настройки базы данных, нажав кнопку «Настройки базы данных».
Нажав на него, мы увидим диалог с настройками, аналогичный тому, что мы привыкли видеть в SQL Server Management Studio:
Отдельно хотелось бы отметить вкладку SQLCMD Variables, на которой мы можем задавать различные переменные для их дальнейшего использования в наших скриптах.
Публикация файла DACPAC
После того, как все настройки установлены и скрипты *.sql добавлены/обновлены, мы можем применить изменения к целевой базе данных.
Для этого зайдите в меню Сборка-> Опубликовать или выберите аналогичный пункт в контекстном меню проекта.
В появившемся диалоговом окне задайте строку подключения к целевой базе данных и, при необходимости, дополнительные настройки, нажав кнопку Дополнительно:
Большинство настроек понятны без дополнительного описания, поэтому мы не будем на них подробно останавливаться, но рекомендую с ними ознакомиться, чтобы в случае, если у вас не получится успешно «опубликовать» проект, вы знали, в чем может быть проблема.
Если вам необходимо выполнить публикацию в целевой базе данных более одного раза, то настройки можно сохранить в профиле публикации, нажав кнопку «Создать профиль».
Это добавит в наш проект файл с расширением *.
publish.xml и в дальнейшем мы сможем публиковать его без повторного входа в настройки.
Если один из профилей публикации должен использоваться по умолчанию, то в контекстном меню файла публикации можно выбрать Установить как профиль публикации по умолчанию.
Этот профиль будет автоматически загружен в диалоговое окно публикации.
Все необходимые изменения можно применить сразу, нажав кнопку «Опубликовать».
Или вы можете отложить его на потом, сгенерировав соответствующий сценарий миграции (кнопка «Создать сценарий») — он будет содержать все необходимые инструкции для приведения целевой базы данных в необходимое состояние.
Если у нас нет доступа к базе данных, то мы можем передать результаты нашей работы в виде файла DACPAC, который создается при компиляции проекта и находится в .
/bin/Debug/Database1.dacpac. Отдав файл, например, администратору базы данных, он, в свою очередь, сможет любым удобным способом применить изменения к целевой базе данных.
Методы публикации DACPAC:
- Бесплатная редакция Visual Studio с установленным SSDT (в частности, для публикации используются клиентские инструменты, входящие в состав DAC Framework и устанавливаемые вместе с SSDT)
- MS SQL Server Management Studio + DAC Framework
- Консольная утилита SqlPackage.exe
- Windows PowerShell ( пример )
- Платформа приложений уровня данных (DACFx) позволяет установить файл DACPAC, вызывая методы из программы C# ( документация И пример )
Заполнение данных
В нашем проекте мы создадим папку DataSeeding (название не имеет значения) и добавим в нее новый скрипт.По сути, все типы в разделе User Script являются обычными *.
sql-скриптами и отличаются только значением свойства «Build Action» вновь создаваемого файла.
Логика из файла PostDeployment.sql будет выполнена после применения всех изменений схемы базы данных.
Если создан PreDeployment.sql, логика будет выполнена до того, как будут применены изменения схемы.
Значение свойства «Действие сборки» для файлов, созданных с помощью шаблона «Скрипт (не в сборке)», будет установлено на «Нет».
Они полезны для удобного структурирования команд в отдельных файлах, которые вызываются из сценариев до или после развертывания.
Файлы, созданные с помощью шаблона «Сценарий», имеют значение «Действие сборки», равное «Сборка», и их содержимое добавляется в результирующий сценарий, который выполняется при публикации файла DACPAC во время изменения схемы базы данных.
В связи с тем, что в проекте может быть только один скрипт Post Deployment и его размер может быстро вырасти, рекомендуется вынести логику вставки данных в отдельные скрипты.
Именно поэтому мы добавим файл типа Script (Not in Build) и добавим ссылку на него в скрипт Post Deployment. Вот как это будет выглядеть:
Теперь при публикации нашего проекта в таблицу «Сотрудники» в базе данных всегда будут вставляться 2 записи.
Инструменты -> SQL-сервер.
Помимо возможности создания проекта базы данных, установка SSDT добавляет ряд полезных инструментов, доступных в меню «Инструменты».
Думаю, из названия уже понятно, что делает каждый из пунктов.
В качестве примера я покажу вам удобный графический инструмент для сравнения схем.
Вы можете выбрать один из трех вариантов источника и цели:
Мы сравним наш проект с локальной базой данных.
Результат сравнения будет выглядеть так:
В появившемся окне мы можем применить различные способы группировки (по схеме, по типу объектов и по необходимому действию), чтобы удобнее просматривать предлагаемые изменения и выбирать те объекты, которые необходимо обновить.
Для того, чтобы применить скрипт миграции, необходимо нажать кнопку «Обновить» — это приведет Target DB в состояние нашего проекта.
Рефакторинг
Это моя любимая функция.В качестве примера мы покажем, как переименовать столбец «Фамилия» в таблице «Сотрудники».
Для этого откройте скрипт создания таблицы, в редакторе таблиц выберите столбец LastName и в меню SQL -> Refactor выберите пункт Rename:
Давайте зададим новое имя:
Смотрим на последствия переименования и применяем предложенные изменения:
В результате все скрипты будут изменены и после первого рефакторинга в проект будет добавлен специальный файл *.
refactoring. Он будет хранить все изменения в схеме в историческом порядке в формате XML-документа.
Эти данные будут полезны при создании сценария миграции и позволят более корректно перенести схему и данные.
Модульное тестирование
Давайте создадим наш первый модульный тест. Для этого вызовем контекстное меню хранимой процедуры, которую мы хотим протестировать:В появившемся диалоговом окне у нас будет возможность выбрать дополнительные объекты (если они есть) и указать тип и имя тестового проекта, а также имя класса, содержащего код модульного теста:
Создав проект, нам будет предложено выбрать базу данных, на которой будут запускаться тесты, а также некоторые настройки проекта:
После успешного создания откроется графический редактор модульных тестов, внизу которого будут представлены различные проверки тестируемого объекта.
В нашем случае это хранимая процедура «EmployeeGetList».
Наша задача сводится к написанию необходимого Sql-скрипта и настройке необходимых условий проверки, которая будет осуществляться после выполнения кода скрипта.
Проверки могут быть разными: время выполнения, количество возвращаемых строк, контрольная сумма возвращаемых данных и т.д. Полный список проверок можно найти в выпадающем меню под текстом скрипта и над таблицей проверок.
Для каждой проверки можно задать ряд настроек через стандартную панель «Свойства».
Для ее вызова выберите Свойства в контекстном меню конкретной проверки.
Например, вот как будет выглядеть проверка количества возвращаемых строк:
А вот как вы можете проверить контрольную сумму:
По сути, эта проверка запускает наш скрипт (получает 2 строки из таблицы «Сотрудники») и находит контрольную сумму по полученным данным.
Наша задача на этапе создания теста — найти эталонные данные, вычислить по ним Checksum и в дальнейшем результат будет сравниваться с этим значением.
Другими словами, это удобный способ гарантировать, что результат хранимой процедуры не изменится.
Для получения эталонного значения Контрольной суммы необходимо воспользоваться кнопкой в окне Свойства, которая позволит выбрать эталонную базу и получить эталонное значение Контрольной суммы:
Заключение
Надеюсь, этот краткий обзор дал вам общее представление о том, что такое SSDT и чем они могут быть полезны в вашем проекте.Конечно, здесь были учтены не все детали.
Но вам, как разработчику, это не нужно.
Вам следует лишь иметь общее представление о списке возможностей, а дальнейшее их использование, надеюсь, будет интуитивно понятным, т.к.
разработчики SSDT хорошо поработали и снабдили инструменты огромным количеством мастеров и контекстных подсказок.
Теги: #базы данных #ssdt #программирование #ms sql-сервер #программирование #.
NET #sql #Microsoft SQL Server
-
Быть Веб-Мастером
19 Oct, 24 -
Хабракат В Rss
19 Oct, 24 -
Рисование Линии
19 Oct, 24 -
Суровые Администраторы Ространснадзора
19 Oct, 24 -
Проблема Эйнштейна
19 Oct, 24
