Как стать автором
Обновить

Комментарии 19

Хабракат бы 8)
дааа
вроде и статьи хорошие пишутся, но без хабраката как-то все портится)
Как пользоваться?
Поставьте <habracut> в месте, где должен быть разрыв. Это и многое другое можно прочесть в разделе помощь. Так-то.
а с подстветкой sql синтаксиса статья была бы еще лучше.
Согласен. Fixed!
Я тут первый раз. Но ставил <habracut/> в начале текста.
в самом-самом-самом начале?

надо:
ля-ля-ля
<habracut/>
ло-ло-ло
Спасибо, теперь буду знать!
А расскажите, чем ваш способ лучше использования Tarantino или Migrator.NET? А то вы во введении напедалили букв руками семь верст до небес, а сравнить с аналогами и не потрудились даже.
Я не стал сравнивать, так как они используют совершенно разный механизм с описываемым. Тут чистый скриптинг без сторонних компонент, от разработчика требуется только дисциплинированность в формировании структуры каталогов и именования файлов. Это больше code convention, при котором еще возможна гибкая процедура миграции.
В тарантино тоже чисто скриптинг, минимум внешней логики. Я так и понял, что вы не стали сравнивать. Наверное, даже и не заглядывали
Вы правы, не смотрел, но проект скачан и ожидает рассмотрения:) Но я и не претендую на универсальность. В названии я так и обозначил «Простой подход». Спасибо за указание на Tarantino.
а проекты баз данных в VS 2008 никак не решают данный вопрос?
или здесь вся фишка в том, чтобы отдать голый .bat на сторону?
но тогда можно и правильно оформленный .sql отдать

а если в проект типа setup свой код закатать, то и с интерактивностью проблем не будет, и с последовательностью установок обновлений
отдаете админу 5 патчей в виде .exe, и он их накатывает по одному на системе, и еще видит, что было и что стало
да, там код нужно написать один раз будет, зато потом как под копирку…

а так, вариантов конечно много можно придумать…
>>а проекты баз данных в VS 2008 никак не решают данный вопрос?
Я писал про «простой» способ. И не все используют VS.

>>но тогда можно и правильно оформленный .sql отдать
Вот я и написал о «правильной организации sql»

>> отдаете админу 5 патчей в виде .exe, и он их накатывает по одному на системе, и еще видит, что было и что стало
Это хорошо когда админ один, а если их много, и некоторым понадобились «непредусмотренные» фишки, как они будут править Ваш exe? Как раз админы больше приветствуют легко модифицируемые скрипты.

>>а так, вариантов конечно много можно придумать…
С нетерпением жду Ваш вариант.
вы не путайте критику статьи с обсуждением тематических вопросов, которые она порождает
к варианту в статье с описанными условиями вопросов нет, общие вопросы есть, они были озвучены
может кто чего полезного скажет, потому и задал их

с «непредусмотренными» фишками можно бороться, зашивая одинаково полный функционал во все версии
потому что поддерживать потом отдельную ветку — это дополнительные затраты
разумеется, во всем нужен баланс

хорошо, вот вам вариант:
можно перевести систему в штатный maintenance, развернуть backup пустой свежей базы, перелить туда данные из предыдущей версии и убить старую базу
да, у такого решения есть свои минусы, но есть и свои плюсы:
— код для переливки зашивается прямо в процедуру БД
— при переливке можно дополнительно проверить целостность данных и внести коррективы
— поскольку старая база убивается, весь клиентский код, не попавший под обновление и не знающий про новую базу, автоматически отсеивается, что иногда мега-удобно

разумеется, по мелочам такое делать не очень правильно, но вот как service pack — очень хороший вариант
наверное, такой вариант можно сравнить с подходом XP, когда сначала пишутся тесты, а потом сам код
так что еще неизвестно, к чему мы в итоге придем со временем )))
посмотрел на Tarantino и Migrator.NET, оба — свободные проекты, висящие на google code
вот мне было бы стремно использовать в работе стороннюю поделку, если уже есть какое-то свое работающее решение
хотя, если разобраться, то может быть все нормально прошло

было бы лучше, если бы был plug-in к VS с аналогичной функциональностью, дающий на выходе скрипт миграции, а еще лучше .exe

ну, может сделают со временем…
SELECT 1/0; — это честно говоря жесть какая-то, почему не сделать более интуитивно понятным с raiserror?
Если рассматривать MSSQL Server, то можно. Однако данный метод писался с претензией на универсальность (независимость от конкрентной базы данных и был портирован из Postgres), поэтому я и оставил 1/0. Но соглашусь, raiserror — выглядит более профессионально
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.