Здравствуйте, Ilias, Вы писали:

I>Здравствуйте,

I>Волею судеб стал разработчиком довольно большого проекта. Большого в плане баз данных. Ну как большого — 9 баз разного размера, в нескольких из них сотни таблиц, view, процедуры тоже есть, в общем не просто данные, код тоже присутствует, 11 (!) linked servers, которые мне, к счастью удалось перелинковать на один и тот же физический и вроде все работает. Крутится это все на MSSQL 2008R2.

I>Т.к. я не настоящий сварщик и это самый крупный проект в смысле баз данных, которые мне в руки попадали, я не очень понимаю, как мне вообще, тсскзать, take ownership тут. До меня его разрабатывал один разработчик, к базам данных там было в комплекте несколько .net и c++ приложений (тут используется .net 3.5 и 2010 студия). Код приложений хранился в локальном svn репозитории и с ним было все нормально. А вот код для баз данных не хранился нигде. Человек просто писал скрипты изменений и рассылал их по почте заинтересованным людям, т.е. никакой версионности не было вообще.

С версией SQL Server 2012 вышел инструмент SQL Server Data Tools (SSDT) под кодовым названием Juneau. Проект начал свое хождение начиная с версии Visual Studio 2010, призван заменить старые vsdb проекты, которые вы упоминали, фактически является инструментом разработчика (администратора) БД MS SQL Server для версий 2005 и выше. SSDT представляет собой бесплатное расширение студии, которое позволяет создавать реляционные базы данных. Кроме всего прочего позволяет работать со всем стеком BI от Microsoft (SSIS, SSAS, SSRS). О возможностях я вскользь упоминал например здесь

Автор: Olaf
Дата: 15.09.15

, более детально с продуктом можно ознакомиться по документации ну и на основании личного опыта. В наши дни поддержка версии для 2010 студии не ведется, но дистрибутив с последними изменениям я думаю можно найти.

I>Теперь прихожу я и мне как-то не очень нравится рассылать скрипты по почте.
I>Подскажите, пожалуйста, кто что может:
I>- как хранят вообще код баз данных? (я видел в студии sql server 2008 проект, этим вообще кто-то пользуется?)

Код БД может хранится в SSDT проекте в рамках большого солюшона студии с .Net, C++ и Web приложениями. Код — это объекты БД и сервера на языке T-SQL.

I>- как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них?

Предложу один из вариантов, их может быть масса. Создаете в этом же проекте PostDeployment скрипт — он может быть один. В этом скрипте вы управляете своими данными, например справочниками. Выглядит это так:

insert into dbo.Table(Id, Name) select 1, 'Привет  1'
insert into dbo.Table(Id, Name) select 2, 'Привет  2'
go
insert into dbo.Table1(Id, Name) select 1, 'Hello  1'
insert into dbo.Table1(Id, Name) select 1, 'Hello  2'
go

Перед выпуском версии вам необходимо выполнить build проекта и опубликовать его локально. Для этих целей на рабочую станцию вместе с SSDT ставится версия LocalDB, которая позволяет вести разработку в так называемом offline режиме. Далее, используя Data Compare вы можете сравнить данные вашей локальной версии БД и тестовой/сертификационной среды. На основании сравнения SSDT сгенерирует вам скрипт, в зависимости от состава данных.

I>- как выявлять неиспользуемые артефакты? скрипты какие-то, утилиты может быть?

Используя SSDT, вы можете выбрать объект БД и нажав на правую кнопку мыши, выбрать пункт References Студия по аналогии с .Net приложениями например, покажет вам ссылки во всех объектах БД, где он упоминается. Исключение составляет динамический SQL sp_executesql 'select * from dbo.Table', здесь студия бессильна.

I>- имеет ли смысл (ну вообще имеет, но имеет ли большой смысл) как-то строго связывать версии приложения и баз данных? и если да, то как.

Все зависит от того как у вас выстроен процесс выпуска и обновления версий и кто этим занимается. Одно время мы практиковали простой вариант. Приложение и БД имеют major и minor версию. Весь комплекс работает только в том случае, если major версия приложения и БД совпадает. Minor версия может расходиться и это оставляет возможность обновления приложения без БД и наоборот, но при этом изменения одновременно не затрагивают и БД и приложение, в противном случае смена major версии. В свое время этого было достаточно. К этой схеме можно подключить build и revision версии.