Есть ли инструмент для создания SQL-скрипта на изменение базы данных?
То есть есть одна версия БД, внесли изменения на девелоперской базе, нужно установить эти изменения и на БД клиентов.
Что-то типа сравнение БД и запись различий в SQL-скрипт.
Нужна бесплатная утилита.

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

S>Есть ли инструмент для создания SQL-скрипта на изменение базы данных?
S>То есть есть одна версия БД, внесли изменения на девелоперской базе, нужно установить эти изменения и на БД клиентов.
S>Что-то типа сравнение БД и запись различий в SQL-скрипт.
S>Нужна бесплатная утилита.

В Visual Studio напримр есть...

Data -> Schema Compare
Data -> Data Compare

Не уверен насчет редакции студии, в 2008 TS — определенно есть.

Но вообще, IMHO здесь не все так просто. У нас например "апдейты" делаются "вручную", примерно так — изменения "на девелоперской базе" делаются девелопером потем создания sql-скрипта, который накатывается на девелоперскую базу. Потом этот же скрипт включается в апдейт, который идет пользователям, и "специальной тулзовиной" накатывается на пользовательские базы тоже. В базе само собой должно быть написано, какие апдейты уже были сделаны чтобы не накатить их повторно (т.е. должна быть специальная таблица под это дело). Или может хватить просто версии базы, если гарантировать, что апдейты накатываются строго в хронологическом порядке и никак иначе.

В общем я в автоматы тут как-то не очень верю, хотя конечно все зависит от ситуации. Разработчику дай волю — он базу кроить начнет как попало, мало задумываясь о том, как эти изменения пойдут пользователям. А если заставить на каждое изменение выдавать скрипт — вразумляет. В основном тогда получается что и девелоперская база обновляется через тот же скрипт. То есть он пишется вначале — лень побеждает

Но все же тут очевидно все зависит от ситуации. Конечно если у вас апдейты — это вбивание 10.000 строк данных например, то это точно другой случай. Но для изменения схемы базы или всяких мелких изменений мы пока ниче лучшего не придумали...

bnk>В общем я в автоматы тут как-то не очень верю, хотя конечно все зависит от ситуации. Разработчику дай волю — он базу кроить начнет как попало,

Причём поиск такого автомата с головой выдаёт компанию, где и разработчики и отдел тестирования сидят на одной базе, которую потом пытаются "синхронизировать" — никогда не мог понять, как можно работать всем на одной базе

bnk> мало задумываясь о том, как эти изменения пойдут пользователям.

Причём и концов потом не сыщешь кто что делал. А так вот репозиторий, вот скрипт, вот ревизия, вот комментарий для чего и кем было сделано, вот ссылка на багтрэкинг, в котором остальные подробности.

Здравствуйте, bnk, Вы писали:
bnk>Но вообще, IMHO здесь не все так просто. У нас например "апдейты" делаются "вручную", примерно так — изменения "на девелоперской базе" делаются девелопером потем создания sql-скрипта, который накатывается на девелоперскую базу. Потом этот же скрипт включается в апдейт, который идет пользователям, и "специальной тулзовиной" накатывается на пользовательские базы тоже.

у нас примерно так же.

автоматическим скриптом мы делаем только проверку что базы версии N получаются структурно идентичными по всем важным цепочкам:
* создание с нуля (первичная установка, новый заказчик)
* upgrade из версии N-1, выпущенной ранее
* upgrade из версии N-2 ...

bnk>...В базе само собой должно быть написано, какие апдейты уже были сделаны чтобы не накатить их повторно (т.е. должна быть специальная таблица под это дело).

мы тоже версию базы пишем, и даже более детальные под-версии.
однако, все upgrade-скрипты сейчас таки пишем в повторно-применяемом стиле (так удобнее получается во время разработки — пока баги ловим, и если надо сливать параллельные ветки):

if object_id('new_table_BBB') is null
   begin
   create table [new_table_BBB] (.....)
   end

if col_length('old_table_AAA','new_column_EEE') is null
   begin
   alter table [old_table_AAA] add [new_column_EEE] nvarchar(100)
   end

bnk>В общем я в автоматы тут как-то не очень верю, хотя конечно все зависит от ситуации. Разработчику дай волю — он базу кроить начнет как попало, мало задумываясь о том, как эти изменения пойдут пользователям.

+1 ... однозначно, "волю давать" можно только под понимание последствий
у нас была целая кампания по поднятию технологии и образованию народа в этой теме. сейчас стало лучше — почти все девелоперы меняют базу, и почти всегда с первой попытки выдают непротиворечивую комбинацию create+upgrade. (а до кампании, код для схемы базы поддерживали 1-2 выделенных человека.)

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

bnk>В Visual Studio напримр есть...

bnk>Data -> Schema Compare
bnk>Data -> Data Compare

bnk>Не уверен насчет редакции студии, в 2008 TS — определенно есть.

В VS 2005 не нашел.

Условия разработки таковы, что можно просто забыть про то, что добавил новый столбец в какую-нибудь таблицу=).
Когда за 2 недели пишешь первый раз серъезную прогу на .net, да плюс с БД на MSSQL2005, и без всяких тестов пускаешь её в промышленную эксплуатацию, потому что НАДО.
А потом нужно срочно её поставить в нескольких подразделениях организации...
А список "хотелок" от пользователей всё увеличивается и требуется, а у тебя кроме этой проги есть и просто работа, и ты не можешь уделять проге много времени.
В общем, "робот" бы не помешал бы=).

S>Условия разработки таковы, что можно просто забыть про то, что добавил новый столбец в какую-нибудь таблицу=).
Так тебе и пишут, что неправильные условия разработки у тебя. Просто раз и навсегда забудь про создание таблиц/колонок/индексов через Студию/КвериАналайзер — нужно писать скрипты, сохранять в файл и иметь процедуру исполнения подобных файлов в один клик.

Здравствуйте, symantis, Вы писали:
S>Условия разработки таковы, что ...
S>Когда за 2 недели пишешь первый раз серъезную прогу на .net, да плюс с БД на MSSQL2005, и без всяких тестов пускаешь её в промышленную эксплуатацию, потому что НАДО.

нифига себе!! про жирненькое, если не секрет и не влом, поделитесь:
1. Вам не страшно?
2. им, тем кому так "надо", им не страшно? они вообще понимают риски?
3. или что это за "промышленность" такая, где это оправдано?
4. и нет возможности добавить еще народ чтобы хоть как-то, параллельно с разработкой тестили?

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

IB>нифига себе!! про жирненькое, если не секрет и не влом, поделитесь:
IB>1. Вам не страшно?
IB>2. им, тем кому так "надо", им не страшно? они вообще понимают риски?
IB>3. или что это за "промышленность" такая, где это оправдано?
IB>4. и нет возможности добавить еще народ чтобы хоть как-то, параллельно с разработкой тестили?

Прога для внутреннего пользования. Контора — одна из госконтор. Денег на покупку\разработку на стороне естественно нет. Ставок чистых программеров нет, да и не должно быть по закону о госслужбе. Так что вариант — самому писать. Зато: спасает десяткам людей драгоценное время на обработку кое-каких данных. И это как-то работает=).