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

S>>1. Обязательно иметь тестовый сервак, на него деплоить только пересозданием базы. В результате имеете постоянно рабочий deployment script для новых инсталляций.
P_K>Разве из проекта нельзя создать скрипт для новой инсталляции? Или у этого тестового сервера иная цель?
Да. Смысл в том, чтобы быть уверенным в работоспособности решения. Часть ошибок возникает только при чистом деплойменте, у меня так с месяц гулял странный баг. Почему студия (тогда 2008я) молчала при обновлении таргет-базы — .

P_K>Расскажите плиз о других способах генерации скрипта, отличных от schema compare.
Основных способов два: либо schema compare, либо deployment script — для юз-кейза с автоматическим обновлением существующей базы мне надо самому освежить матчасть, чуть попожже отпишусь.

P_K>Улучшения 2010 студии не перекрываются её сыростью? А то мы пока решили дождаться SP1.
Нет. Я явных багов в самой VS не заметил. Вот в extensions их дофига.

P_K>- Сейчас VSTSDB 2008 с GDR R2 выдаёт ворнинги (unresolved reference to object), если в хранимке используется временная таблица (вида #table). Примечательно, что в Management Studio для R2 такие временные таблицы начали распознаваться Intellisence.
Сам не сталкивался, но что-то такое на официальном форуме обсуждалось. У нас временные таблицы (как и курсоры) не используются вообще, даже довольно сложные алгоритмы типа разграничения доступа как-то удаётся сделать чистым sql'ем. Вот табличные переменные где-то были...

P_K>Как оказалось 2008R2 не поддерживается, нужно юзать 2010 студию.
Да.

S>>- обязательные точки с запятой
P_K>Расскажите поподробнее, какие могут быть проблемы
Features Not Supported in a Future Version of SQL Server (остальные deprecated также не стоит использовать):

Transact-SQL
Not ending Transact-SQL statements with a semicolon.

Кроме этого, из мелких доводов: явная декларация намерений, тот же with требует перед собой точку с запятой,

P_K>1. Пара разработчиков работают над проектом БД (каждый над своей веткой), деплоят в одну разработчискую базу.
Да, цепочка такая: update-fix-deploy-fix-deploy-...-commit
*fix — правим возникшие багоглюки.
Если у вас при деплойменте на тестовый сервер выполняются тесты — ещё лучше.

P_K>2. Когда работы завершены и все изменения смёржены, один из разработчиков с помощью Schema compare (проекта и схемы рабочей базы) генерирует скрипт со всеми изменениями. Тщательно просматривает его и деплоит на рабочую базу.
Да. Первые проверки можно сделать в самой Schema compare — копаем её настройки.
Особый гемморой при деплойменте — sqlcmd variables. В 2008 студии Schema Compare может нагенерить скрипт, полный $(var).