Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Миграция проектов на MSSQL 2012, трудности  [new]
Yuri Abele
Member

Откуда: Латвия> Литва > Тольятти > Wiesbaden > Karlsruhe
Сообщений: 1661
Привет!

Мигрируем мы с MSSQL-2008R2 на MSSQL2012.
Мигрируем все - начиная от самих баз данных до SSIS, SSAS и SSRS.
Все разработки производим в Visual Studio.

Шаг первый - проекты баз данных (SQL Server Database Project).
Важно:
- SSDT (SQL Server Data Tools) установлены самые последние
- VS 2010 SP1 установлен

1.1. Удивило то, что в списке типов проектов для MSSQL нет 2012 (Add New Project => Database => SQL Server), а есть только 2005 и 2008. Они существуют?

1.2. Не удается найти master.dbschema и msdb.dbschema файлы для 2012, а соответственно есть только для 2005 и 2008.
Интернет рыл по [ "master.dbschema" "SQL Server" 2012 ] и ничего толком не нашел. Они вообще существуют?
3 мар 14, 15:19    [15663459]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
Yuri Abele
Member

Откуда: Латвия> Литва > Тольятти > Wiesbaden > Karlsruhe
Сообщений: 1661
Похоже, что SQL Server Data Tools поверх уже установленного VS 2010 Ultimate как-то не так установился :-/
3 мар 14, 15:48    [15663738]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
Yuri Abele
Member

Откуда: Латвия> Литва > Тольятти > Wiesbaden > Karlsruhe
Сообщений: 1661
Ёкарный бабай! Простите, что ругаюсь против правил форума, но я не смог удержаться!
Вот Microsoft нам удружила ...

В общем, все у меня корректно установлено было (и есть), дело в другом.
Дело в том, что не существует больше SQL Server Database Project. Точнее его нет для MSSQL 2012.
Меня смутило то, что в момент открытия старых проектов VS предложил сконвертировать, а потом в Deployment Targets увидел только 2005 и 2008 серверы.
Оказывается, если мы хотим, с помощью VS 2010 или позже разрабатываться базы данных под MSSQL 2012 или старше и при этом у нас есть готовые проекты для <= 2008R2, то шаги следующие:
A. Генерим из MSSQL Database проекта (в старом формате) необходимые базы данных
B. Средствами SSMS (SQL Server Management Studio) переключаем базу данных в формат 2012
C. Создаем в "новом" Visual Studio новый SQL Server проект и импортируем в него структуру созданной базы данных (т.е. Reverse Engineering). Сохраняем.

При этом мы получаем совсем другой тип проекта, с другими файлами. Где для каждой таблицы создается только один "all inclusive" файл - со всеми сопутствующими объектами (индексами и констрейнтами).
Если же нам надо каждый объектик отдельным файлом - получаем удовольствие делить все руками.
Хорошо если база данных одна и небольшая. А если их много и с кучей объектов? В моем случае суммарно несколько тысяч таблиц в порядка сотни баз ...
К тому же, все комментарии, которые были не инкомпилированы теряются. Теперь придется работая на двух экранах руками перетягивать все из старых проектов в новые...

Я в трауре, пойду удавлюсь
3 мар 14, 19:24    [15665259]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
Yuri Abele,

Берете 2012 студию, берете базу, создаете в студии SSDT-проект под 2012 и затягиваете в него эту базу.
Yuri Abele
При этом мы получаем совсем другой тип проекта, с другими файлами. Где для каждой таблицы создается только один "all inclusive" файл - со всеми сопутствующими объектами (индексами и констрейнтами). Если же нам надо каждый объектик отдельным файлом - получаем удовольствие делить все руками.
Поверьте, это гораздо лучше, чем то, как вели себя предыдущие версии студии. Когда такой файл с индексом или форейном должен был удалиться при сравнении схемы, но не удалялся и потом начинал гадить в деплойменте - то ли он есть, то ли его нет. А все потому, что такой констрейнт можно было удалить двумя способами, как констрейнт и как файл. Многие не видели в этом разницы, в результате такие проекты начинали стремительно замусориваться.
Теперь все гораздо компактнее. А главное, студия без вопросов удаляет файлы с любыми объектами из проекта, подчистую, если я выбрал удаление этого объекта в Schema Compare. Раньше же оставался мусор.
Yuri Abele
Хорошо если база данных одна и небольшая. А если их много и с кучей объектов? В моем случае суммарно несколько тысяч таблиц в порядка сотни баз ...
У вас сотня разных проектов БД? Действительно разных? Или схема одинаковая, а отличаются только пользователи? Ну так не включайте в проект пользователей, все равно им там делать нечего.
Yuri Abele
комментарии, которые были не инкомпилированы
Что, простите?..
4 мар 14, 04:40    [15667009]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
Yuri Abele
Дело в том, что не существует больше SQL Server Database Project. Точнее его нет для MSSQL 2012.
Средства разработки у MS для сиквела действительно рудиментарные.
MS в последнее время приложила некие усилия в этом направлении, но они свелись к разработке системы для чайников, уровня базы для веб-сайтика. То есть цель была - сделать средство разработки баз для веб-программиста.

Для сиквелиста разрабатывать можно было, если сделать свою систему разработки над Visual Studio, сама VS расчитана на неспециалиста.
Ну и при этом VS 2010 перестала поддерживать проекты старого типа - то есть при использовании VS 2010 и MSSQL 2012 нужно просто заново разработать систему разработки, новую надстройку. Я пока MSSQL 2012 не использовал, не могу подсказать, насколько это сложно и что можно взять из старого.
4 мар 14, 08:41    [15667167]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
Yuri Abele
Теперь придется работая на двух экранах руками перетягивать все из старых проектов в новые...
Да, главное - теряется история изменений и их привязка к таскам, багам и бизнес-требованием, это просто в разы увеличивает трудоёмкость работ в течении года-двух...
В общем, удружили :-(
4 мар 14, 08:47    [15667182]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
Ennor Tiegael
Берете 2012 студию, берете базу, создаете в студии SSDT-проект под 2012 и затягиваете в него эту базу.
Для софтверной фирмы (подразделения) это можно назвать "потерять исходники", но взамен получить возможность вытянуть декомпилированный код из работающей системы.

То есть фирма может и не развалится, но потери действительно огромны.
4 мар 14, 08:52    [15667195]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
alexeyvg
Ennor Tiegael
Берете 2012 студию, берете базу, создаете в студии SSDT-проект под 2012 и затягиваете в него эту базу.
Для софтверной фирмы (подразделения) это можно назвать "потерять исходники", но взамен получить возможность вытянуть декомпилированный код из работающей системы.

То есть фирма может и не развалится, но потери действительно огромны.
Применительно к БД - не вижу разницы. Пример можно?
4 мар 14, 09:50    [15667442]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
super-code
Member

Откуда:
Сообщений: 244
Ennor Tiegael, да например PostDeployment скрипты.
Разные варианты установки в зависимости от значения переменных проекта базы.
Коды ошибок самого сервера.

И много чего ещё. Я тоже с этим столкнулся, ужасно, что проект не может правильно конвертироваться из версии для 2008 в версию 2012.
4 мар 14, 10:20    [15667618]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
super-code,

А, вы имеете в виду, что эти вещи не конвертируются нормально? Потому что функционал никуда не делся - я точно помню, что делал Post-Deployment script в SSDT 2012, например.

Может быть, не знаю. Настолько развесистый деплой мне делать не приходилось, обычно было достаточно перевытянуть сырцы из БД. В тех же случаях, когда база требовала инициализации данных после своего создания, это делалось из специальных хранимок. Простыни кода, конечно, были те еще, зато ничего не теряется.
4 мар 14, 10:48    [15667773]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
super-code
Member

Откуда:
Сообщений: 244
Ennor Tiegael
А, вы имеете в виду, что эти вещи не конвертируются нормально?


Да речь, про то, что проект базы не конвертируется, нужно создавать новый проект и вещи перечисленные мной из исходников теряются. Это я привел Вам "пример" на сообщение:

Ennor Tiegael
alexeyvg
пропущено...
Для софтверной фирмы (подразделения) это можно назвать "потерять исходники", но взамен получить возможность вытянуть декомпилированный код из работающей системы.

То есть фирма может и не развалится, но потери действительно огромны.
Применительно к БД - не вижу разницы. Пример можно?
4 мар 14, 11:15    [15668004]     Ответить | Цитировать Сообщить модератору
 Re: Миграция проектов на MSSQL 2012, трудности  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31444
Ennor Tiegael
alexeyvg
пропущено...
Для софтверной фирмы (подразделения) это можно назвать "потерять исходники", но взамен получить возможность вытянуть декомпилированный код из работающей системы.

То есть фирма может и не развалится, но потери действительно огромны.
Применительно к БД - не вижу разницы. Пример можно?
Пример чего, пример потери истории изменений кода процедуры с привязками к бизнес-требованиям и комментариями заинтересованных лиц, связей с изменениями клиентских приложений и т.п.?

Не понял вопроса.
Ennor Tiegael
Настолько развесистый деплой мне делать не приходилось, обычно было достаточно перевытянуть сырцы из БД
Видимо в этом дело.
У меня на прошлой работе при деплой делался на два десятка серверов, с удалением и созданием репликаций, с временным отключением некоторого функционала для некоторых пользователей на время деплоя и т.д. Это всё не сделать методом "перевытянуть сырцы из БД"

Ну ладно, такие проекты исключение, но даже для обычных скромных проектов (как у меня сейчас), потеря истории изменений, как я уже писал, понижает производительность труда в несколько раз, это просто катастрофа.
4 мар 14, 13:50    [15669495]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить