Комментарии 19
Хабракат бы 8)
дааа
вроде и статьи хорошие пишутся, но без хабраката как-то все портится)
вроде и статьи хорошие пишутся, но без хабраката как-то все портится)
Как пользоваться?
Поставьте <habracut> в месте, где должен быть разрыв. Это и многое другое можно прочесть в разделе помощь. Так-то.
а с подстветкой sql синтаксиса статья была бы еще лучше.
Я тут первый раз. Но ставил <habracut/> в начале текста.
А расскажите, чем ваш способ лучше использования Tarantino или Migrator.NET? А то вы во введении напедалили букв руками семь верст до небес, а сравнить с аналогами и не потрудились даже.
Я не стал сравнивать, так как они используют совершенно разный механизм с описываемым. Тут чистый скриптинг без сторонних компонент, от разработчика требуется только дисциплинированность в формировании структуры каталогов и именования файлов. Это больше code convention, при котором еще возможна гибкая процедура миграции.
а проекты баз данных в VS 2008 никак не решают данный вопрос?
или здесь вся фишка в том, чтобы отдать голый .bat на сторону?
но тогда можно и правильно оформленный .sql отдать
а если в проект типа setup свой код закатать, то и с интерактивностью проблем не будет, и с последовательностью установок обновлений
отдаете админу 5 патчей в виде .exe, и он их накатывает по одному на системе, и еще видит, что было и что стало
да, там код нужно написать один раз будет, зато потом как под копирку…
а так, вариантов конечно много можно придумать…
или здесь вся фишка в том, чтобы отдать голый .bat на сторону?
но тогда можно и правильно оформленный .sql отдать
а если в проект типа setup свой код закатать, то и с интерактивностью проблем не будет, и с последовательностью установок обновлений
отдаете админу 5 патчей в виде .exe, и он их накатывает по одному на системе, и еще видит, что было и что стало
да, там код нужно написать один раз будет, зато потом как под копирку…
а так, вариантов конечно много можно придумать…
>>а проекты баз данных в VS 2008 никак не решают данный вопрос?
Я писал про «простой» способ. И не все используют VS.
>>но тогда можно и правильно оформленный .sql отдать
Вот я и написал о «правильной организации sql»
>> отдаете админу 5 патчей в виде .exe, и он их накатывает по одному на системе, и еще видит, что было и что стало
Это хорошо когда админ один, а если их много, и некоторым понадобились «непредусмотренные» фишки, как они будут править Ваш exe? Как раз админы больше приветствуют легко модифицируемые скрипты.
>>а так, вариантов конечно много можно придумать…
С нетерпением жду Ваш вариант.
Я писал про «простой» способ. И не все используют VS.
>>но тогда можно и правильно оформленный .sql отдать
Вот я и написал о «правильной организации sql»
>> отдаете админу 5 патчей в виде .exe, и он их накатывает по одному на системе, и еще видит, что было и что стало
Это хорошо когда админ один, а если их много, и некоторым понадобились «непредусмотренные» фишки, как они будут править Ваш exe? Как раз админы больше приветствуют легко модифицируемые скрипты.
>>а так, вариантов конечно много можно придумать…
С нетерпением жду Ваш вариант.
вы не путайте критику статьи с обсуждением тематических вопросов, которые она порождает
к варианту в статье с описанными условиями вопросов нет, общие вопросы есть, они были озвучены
может кто чего полезного скажет, потому и задал их
с «непредусмотренными» фишками можно бороться, зашивая одинаково полный функционал во все версии
потому что поддерживать потом отдельную ветку — это дополнительные затраты
разумеется, во всем нужен баланс
хорошо, вот вам вариант:
можно перевести систему в штатный maintenance, развернуть backup пустой свежей базы, перелить туда данные из предыдущей версии и убить старую базу
да, у такого решения есть свои минусы, но есть и свои плюсы:
— код для переливки зашивается прямо в процедуру БД
— при переливке можно дополнительно проверить целостность данных и внести коррективы
— поскольку старая база убивается, весь клиентский код, не попавший под обновление и не знающий про новую базу, автоматически отсеивается, что иногда мега-удобно
разумеется, по мелочам такое делать не очень правильно, но вот как service pack — очень хороший вариант
наверное, такой вариант можно сравнить с подходом XP, когда сначала пишутся тесты, а потом сам код
так что еще неизвестно, к чему мы в итоге придем со временем )))
к варианту в статье с описанными условиями вопросов нет, общие вопросы есть, они были озвучены
может кто чего полезного скажет, потому и задал их
с «непредусмотренными» фишками можно бороться, зашивая одинаково полный функционал во все версии
потому что поддерживать потом отдельную ветку — это дополнительные затраты
разумеется, во всем нужен баланс
хорошо, вот вам вариант:
можно перевести систему в штатный maintenance, развернуть backup пустой свежей базы, перелить туда данные из предыдущей версии и убить старую базу
да, у такого решения есть свои минусы, но есть и свои плюсы:
— код для переливки зашивается прямо в процедуру БД
— при переливке можно дополнительно проверить целостность данных и внести коррективы
— поскольку старая база убивается, весь клиентский код, не попавший под обновление и не знающий про новую базу, автоматически отсеивается, что иногда мега-удобно
разумеется, по мелочам такое делать не очень правильно, но вот как service pack — очень хороший вариант
наверное, такой вариант можно сравнить с подходом XP, когда сначала пишутся тесты, а потом сам код
так что еще неизвестно, к чему мы в итоге придем со временем )))
посмотрел на Tarantino и Migrator.NET, оба — свободные проекты, висящие на google code
вот мне было бы стремно использовать в работе стороннюю поделку, если уже есть какое-то свое работающее решение
хотя, если разобраться, то может быть все нормально прошло
было бы лучше, если бы был plug-in к VS с аналогичной функциональностью, дающий на выходе скрипт миграции, а еще лучше .exe
ну, может сделают со временем…
вот мне было бы стремно использовать в работе стороннюю поделку, если уже есть какое-то свое работающее решение
хотя, если разобраться, то может быть все нормально прошло
было бы лучше, если бы был plug-in к VS с аналогичной функциональностью, дающий на выходе скрипт миграции, а еще лучше .exe
ну, может сделают со временем…
SELECT 1/0; — это честно говоря жесть какая-то, почему не сделать более интуитивно понятным с raiserror?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой подход к версионированию баз данных MS SQL Server