Zelius,

Если вы не используете SSDT, то в чем же вы разработку БД ведете? Просто интересно.

Zelius,

Жесть. Окей, попробую вкратце описать возможный воркфлоу. Сразу скажу, что это не единственный возможный подход, но в моих обстоятельствах я так делал, и все работало. Если у вас система на продажу, с кучей клиентов, то задача усложняется, хотя невозможной это ее не делает - я лично знаю как минимум одну компанию, которая ведет свою БД в SSDT и которая продает свою систему и предоставляет возможность кастомизации под нужды отдельных клиентов (Fenergo). Как именно они это делают, и сколько ручного труда у них на это тратится - без понятия, но учитывая, что многие вещи можно сделать через командную строку с msbuild, возможно они многое автоматизировали.

А, да - насчет лицензий. Если у вас в компании есть лицензии VS, то все просто - ставите VS 2019 (ну или последнюю, какая будет в будущем) соотв. редакции и вперед. Если нет, то ставите Community Edition и при установке выбираете единственный workload - Data Processing или как-то там. В этом случае лицензия не нужна .

На каждую из имеющихся у вас БД создаете отдельный проект базы в SSDT. После создания проекта и выставления его настроек (коллейшн и прочее) в панели Solution Explorer правой кнопкой на проекте -> Import Schema . Затягиваете из имеющейся БД всю схему в проект, потом смотрите есть ли ошибки. Сначала билдите проект, потом пытаетесь задеплоить его в пустую БД. Последнее, на самом деле, довольно надежный тест, ловит очень многое (но конечно не всё).

Зависимости между базами в SSDT реализуются через механизм Database Reference . Сразу скажу, что чистить свеже-импортированный код, чтобы заменить все 3- и 4-частные имена на соответствующие SQLCMD-переменные, это как чистить ведро ершей - работка та еще, и запросто может занять несколько дней на большой и сложноподчиненной базе. По счастью, в основной своей части это просто тупая рутина в виде кучи Ctrl-Shift-F / Ctrl-Shift-H. Кроме того, конкретно эту задачу обычно приходится выполнять только один раз, в процессе перевода разработки на SSDT. Постепенно народ привыкает, что все изменения должны исходить из проекта, а не из базы, несогласных увольняют, и ситуация стабилизируется.
Единственная серьезная проблема, с которой можно столкнуться на этой стадии - это циклические зависимости между БД. Тут скорее всего вам придется заняться редизайном, потому что подобная ситуация неправильна в принципе, и будет создавать проблемы при любом способе деплоймента, какой бы вы ни выбрали. В идеале, граф зависимостей между вашими БД должен быть направленным и ациклическим (а еще лучше - деревом).

Собственно написание кода в SSDT не отличается от любого другого редактора. Разве что обращение к объектам других БД приходится делать через SQLCMD-переменные, типа:

Деплой изменений из проекта в базу можно делать несколькими способами:

• Во-первых, есть Schema Compare , где можно точечно исключить объекты или классы объектов (чаще всего это пользователи и их членство в ролях, т.к. эти вещи как правило environment-specific, и в проект их лучше не включать вообще).
  
• Во-вторых, можно создать Publishing Profile и включить его в проект как отдельный файл (и как следствие, включить его в source control). Насколько я понимаю, его можно будет дергать из командной строки, через вызов msbuild.
  

Оба эти способа позволяют как выкатить изменения напрямую, так и сгенерировать скрипт с изменениями, который при необходимости можно подправить вручную, перед его выполнением.

Также имеется Data Compare , которую можно использовать для быстрого деплоя эталонных данных на тестовую БД.

Про полную интеграцию с Git, полагаю, можно даже не упоминать.


В принципе, вроде бы все. Из моего личного опыта могу сказать, что на данный момент я внедрял SSDT в трех компаниях (причем я там был контрактором, а не перманентным эмплоем, и делал это по собственной инициативе), и во всех случаях внедрение было успешным. Естественно, поначалу люди сопротивляются, но когда они видят преимущества, которые дает данный тул, и им удается перестроить свой способ мышления, то в конечном итоге некоторые даже говорят "спасибо".

P.S. Если вы посмотрите внимательно, то заметите, что большая часть приведенных ссылок ведет на один и тот же раздел в документации. Пошерстите там, наверняка найдете много полезного.

Неудобно, я видел как выглядит данный процесс, деплой базы занимает целый день.

Такая ситуация: допустим вы добавили новое поле в таблицу. Как ваша тулза будет генерить change script - через drop / create, что ли? Или вы храните не единственный create table, а всю цепочку альтеров в скрипте создания таблицы? Представляю, как будет выглядеть такой скрипт после добавления пары десятков столбцов.

В SSDT такой проблемы нет, она все это понимает и умеет. В проекте хранятся именно что скрипты создания объектов, а как именно будет выглядеть change script, переводящий базу из произвольного состояния в состояния проекта, генерится на ходу.
Логины, за редким исключением, в проект помещать не стоит, хотя безусловно это можно сделать. При деплое их можно исключить из сравнения, как в Schema Compare, так и в Publishing Profile (не знаю, как быть в случае с dacpac, не пользовался этим механизмом никогда, но скорее всего должен быть способ).
Насчет ошибок при выборке из xml - не понял. В старых версиях были моменты, когда SSDT не понимала какой-то легальный синтаксис, сталкивался с этим, но это все фиксится .
Также не очень понял, что именно вы называете пре- и пост-деплоями. В SSDT это есть , но они работают только при развертывании через publish profile, а Schema Compare их игнорирует. Что вы туда собираетесь помещать такого, чтоб прям каждый раз выполнять надо было?
Сильно связанные базы это вообще изрядная головная боль. Можно спросить себя, а нужны ли отдельные базы как таковые, если они настолько сильно связаны? Может проще все перенести в одну.
У меня был один случай, когда горе-девелоперы сделали кучу циклических ссылок между основной и дополнительной БД. Ну, историю про Гордиев узел помните? Вот как-то так.
Когда вы добавляете Database Reference в проект, то для него автоматически создается SQLCMD-переменная, по которой вы обращаетесь к объектам внутри этого референса.