Microsoft SQL Server Data Tools, SavePearlHarbor

Ще одна копія хабора

Головне меню

Навігація за записами

Microsoft SQL Server Data Tools

У цій статті хотів би розповісти про набір корисних додатків до Visual Studio, які можуть значно полегшити розробку баз даних на основі MS SQL Server. Основними перевагами використання SSDT я виділив би наступне:

можливість простої зміни (refactoring) схеми бази (можна перейменувати колонку таблиці і всі Views, Functions і Stored Procedures, що посилаються на неї, автоматично будуть виправлені для відображення змін)
створення юніт тестів для бази даних
зберігання структури бази даних у Source Control
порівняння схеми/даних з можливістю генерації скрипта для приведення схеми/даних до необхідного стану

Безумовно, на цьому плюси використання SSDT не закінчуються, але решта не так сильно вражає, як те, що згадано вище. Якщо вас цікавить, як скористатися цими та іншими перевагами – прошу під кат.

Установка та перше знайомство

Все необхідне для встановлення можна знайти на сторінці завантаження в Data Developer Center. Вибравши необхідну версію, ви зможете легко встановити інструменти на свій комп'ютер і описувати це не бачу сенсу. Після встановлення у вікні створення нового проекту з'явиться новий тип проекту:

Створивши новий проект, ви побачите наступне:

На панелі SQL Server Object Explorer (меню View - SQL Server Object Explorer) ми бачимо щось дуже схоже на Object Explorer в SQL Server Management Studio, з якого прибрано все, що не має великого сенсу на етапі розробки бази даних. Підключившись до існуючої бази, можна робитирозробку бази даних у так званому Connected режимі. Це мало чим відрізняється від класичного підходу, що використовується в SQL Server Management Studio і в цій статті не розглядатиметься.

Disconnected режим

Script (*.sql)– додає один або кілька *.sql файлів із заданого розташування у структуру проекту;
Data-tier Application (*.dacpac)– додає *.sql файли, а також різні налаштування бази даних із спеціального DACPAC файлу, описаного вище; може містити не тільки схему бази, але також дані та різні налаштування бази;
Database…— аналогічний попередньому варіанту, але джерелом даних є існуюча база

Ми виберемо варіант “Database…” та імпортуємо локальну базу. Вона містить одну таблицю і одну процедуру, що зберігається. У SQL Server Object Explorer вихідна база виглядає так:

Після завершення імпорту ми побачимо вкрай схожу картину, з тією єдиною відмінністю, що структура бази буде представлена в Solution Explorer як *.sql файлів.

Також ми завжди можемо додати нові елементи, скориставшись діалоговим вікном Add New Item, в якому перераховані всі можливі об'єкти бази даних:

Додамо таблицю TestTable. Новий файл-скрипт TestTable.sql буде доданий до кореня проекту і для зручності ми його перенесемо до папки Tables.

Для створення схеми таблиці ми можемо використовувати панель дизайнера, так і панель T-SQL. Всі зміни, зроблені на одній панелі, будуть відразу відображені в іншій. Так само ми можемо змінювати існуючі скрипти. Visual Studio для цього надає зручний та улюблений усіма IntelliSense. Оскільки ми не підключені до фізичної бази даних, Visual Studio для коректної роботиIntelliSence парсить усі скрипти у проекті, що дозволяє їй миттєво відображати останні зміни, зроблені у схемі бази даних.

Властивість Target platform дозволяє виставити версію бази даних, для якої валідуватимуться скрипти в проекті. Мінімальна версія MS SQL Server 2005, що підтримується. Якщо наприклад задати версію бази 2005 і спробувати створити колонку типу Geography, то при компіляції ми отримаємо наступне повідомлення:

На закладці Project Settings, ми можемо встановити параметри бази даних, натиснувши на кнопку Database Settings. Натиснувши на неї, ми побачимо діалог з налаштуваннями, аналогічні тим, що ми звикли бачити в SQL Server Management Studio:

Також хочеться згадати закладку SQLCMD Variables, на якій ми можемо задавати різні змінні для подальшого їх використання в наших скриптах.

Публікація файлу DACPAC (publishing)

Після того, як всі налаштування задані і *.sql скрипти додані/оновлені, ми можемо застосувати зміни до цільової бази (target database). Для цього йдемо в меню Build->Publish або вибираємо аналогічний пункт у контекстному меню проекту.

У діалоговому вікні задаємо рядок підключення до бази призначення (target database) і якщо необхідно - додаткові налаштування, натиснувши на кнопку Advanced:

Більшість налаштувань зрозумілі без додаткового опису, тому не будемо на них докладно зупинятися, але рекомендую з ними ознайомитися, щоб у разі неможливості успішно «запаблишити» проект, ви знали в чому може бути проблема.

Безкоштовна редакція Visual Studio із встановленими SSDT (зокрема для publish використовуються клієнтські інструменти, що входять до складу DAC Framework, що встановлюються разом із SSDT)
MS SQL Server Management Studio + DACFramework
Консольна утиліта SqlPackage.exe
Windows PowerShell (приклад)
Data-tier Application Framework (DACFx) дозволяє поставити DACPAC файл шляхом виклику методів з C# програми (документація і приклад)

Data Seeding

У нашому проекті створимо папку DataSeeding (ім'я не має значення) і до неї додамо новий скрипт.

По суті всі типи в розділі User Script є звичайними скриптами *.sql і відрізняються лише значенням властивості “Build Action” у новоствореного файлу.

Логіка з файлу PostDeployment.sql буде виконана після всіх змін схеми бази даних. У разі створення PreDeployment.sql – логіка виконається перед застосуванням змін схеми. Значення властивості Build Action для файлів, створених через шаблон Script (Not in Build), буде встановлено в «None». Вони є корисними для зручного структурування команд в окремих файлах, які викликаються з Pre або Post Deployment скриптів. Файли створені через шаблон Script мають значення Build Action, що дорівнює «Build», і їх вміст додається до результуючого скрипту, який виконується при publish'e DACPAC файлу в момент зміни схеми бази. У зв'язку з тим, що в проекті може бути лише один Post Deployment script і його розмір може швидко зрости, рекомендується логіку вставки даних виносити в окремі скрипти. Саме тому ми додамо файл типу Script (Not in Build), а Post Deployment script додамо посилання на нього. Ось як це виглядатиме:

Tools -> SQL Server

Поруч із можливістю створення Database проекту, установка SSDT додає ряд корисних інструментів, доступних у меню Tools.

Думаю, що з назви і так зрозуміло, що кожен із пунктів робить. Як приклад, покажу зручний графічнийІнструмент порівняння схем. Як джерело і цільовий об'єкт можна вибрати один з трьох варіантів:

Ми порівняємо наш проект із локальною базою даних. Результат порівняння виглядатиме так:

Refactoring

Задаємо нове ім'я:

Переглядаємо наслідки перейменування та застосовуємо запропоновані зміни:

В результаті всі скрипти будуть змінені і після першого рефакторингу до проекту буде додано спеціальний файл *.refactoring. У ньому зберігатимуться всі зміни схеми в історичному порядку у форматі XML документа. Ці дані будуть корисні при генерації міграційного скрипту і дозволять правильно мігрувати схему і дані.

Unit testing

Створимо наш перший юніт тест. Для цього викличемо контекстне меню для процедури, яку ми хочемо протестувати:

У діалоговому вікні, що з'явиться, у нас буде можливість вибрати додаткові об'єкти (якщо вони є) і задати тип та ім'я тестового проекту та ім'я класу, що містить код юніт тесту:

Створивши проект, нам буде запропоновано вибрати базу даних на якій будуть запускатися тести, а також деякі налаштування проекту:

Наше завдання зводиться до того, щоб написати необхідний Sql скрипт і задати необхідні умови перевірки, які будуть зроблені після виконання коду скрипта. Перевірки можуть бути різні: час виконання, кількість повернутих рядків, Checksum повернутих даних тощо. Повний список перевірок можна знайти у меню під текстом скрипта і над таблицею перевірок. Для кожної перевірки можна встановити ряд налаштувань через стандартну панель Properties. Для її виклику необхідно в контекстному меню конкретної перевірки вибрати Properties. Наприклад, ось так виглядатиме перевірка повертаєтьсякількості рядків:

А ось так можна перевірити Checksum:

По суті, ця перевірка виконує наш скрипт (отримує 2 рядки з таблиці Employees) і на отриманих даних знаходить Checksum. Наше завдання на етапі створення тесту, знайти еталонні дані, на них порахувати Checksum і надалі з цим значенням буде здійснюватись звірка отриманого результату. Іншими словами, це зручний спосіб переконатися, що результат процедури, що зберігається, не змінюється. Для отримання контрольного значення Checksum необхідно скористатися кнопкою у вікні Properties, яка дозволить вибрати еталонну базу та отримати еталонне значення Cheсksum:

Висновок

Сподіваюся, цей короткий огляд дозволив отримати загальне уявлення, що таке SSDT і як вони можуть бути корисні у вашому проекті. Безумовно, тут не були розглянуті всі деталі. Але вам як розробнику це і не потрібно. Ви повинні мати загальне уявлення списку можливостей, а подальше їх використання сподіваюся буде інтуїтивно зрозумілим, т.к. розробники SSDT добре попрацювали та забезпечили інструменти величезною кількістю помічників (wizards) та контекстних підказок.