Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Хорошая статья, только вопрос, есть ли возможность миграции данных вместе со структурой, скажем: 1) создать столбец, 2) выполнить запрос / заполнить значениями 3) Изменить тип на Not Null 4) создать вторичныи ключ.
Возможно это и полезный инструмент, для тех кому действительно необходимо двигаться по версиям базы как вверх так и вниз. Но имхо большинство обновлений БД делаются в одном направлении. А необходимость в 10 версиях базы это больше похоже на плохо организованный процесс разработки и сопровождения продукта, чем на реальную необходимость.
И для выполнения однонаправленных изменений уже есть вполне вменяемый инструмент в студии (в VS2008 он шел отдельно как DataDude, в 2010 — встроенный) — Schema\Data compare, генерящий sql-скрипты а не .NET. Для возврата назад — достаточно восстановить бэкап ( вы ведь делаете бэкапы перед изменениями структуры, не так ли ;) ?). Возвращаться на 3-5 версий назад — имхо странное удовольствие. Но даже тут — если вы храните схемы в VCS (в студии есть тип проекта для бд), то достаточно откатиться к конкретной версии проекта и «задеплоить» результат.
В общем есть подозрения что многие разработчики знают о вышеописанных возможностях студии и им не очень понятно, зачем для разработки БД писать еще и .net код для развертывания. Поэтому нет и массовых восторженных реакций.
Ваш К.О.
И для выполнения однонаправленных изменений уже есть вполне вменяемый инструмент в студии (в VS2008 он шел отдельно как DataDude, в 2010 — встроенный) — Schema\Data compare, генерящий sql-скрипты а не .NET. Для возврата назад — достаточно восстановить бэкап ( вы ведь делаете бэкапы перед изменениями структуры, не так ли ;) ?). Возвращаться на 3-5 версий назад — имхо странное удовольствие. Но даже тут — если вы храните схемы в VCS (в студии есть тип проекта для бд), то достаточно откатиться к конкретной версии проекта и «задеплоить» результат.
В общем есть подозрения что многие разработчики знают о вышеописанных возможностях студии и им не очень понятно, зачем для разработки БД писать еще и .net код для развертывания. Поэтому нет и массовых восторженных реакций.
Ваш К.О.
Я немного предвзят, но постараюсь ответить.
Во-первых, по поводу встроенного. Встроено оно начиная с Premium, что уже само по себе внушает. К тому же, как почти все Майкрософтовское, сильно страдает от «блоатянки» и энтерпрайзнутых функций. Плюс ко всему для ее нормальной работы нужно уж очень много приседаний — те же рефакторинги для простейших операций.
Во-вторых, насчет миграций в обе стороны. В бою, разумеется, назад редко когда мигрировать приходится, но в разработке подобная возможность очень и очень помогает. Поправил схему, пощупал, что она из себя представляет, не понравилось — откатил и начал заново.
Во-первых, по поводу встроенного. Встроено оно начиная с Premium, что уже само по себе внушает. К тому же, как почти все Майкрософтовское, сильно страдает от «блоатянки» и энтерпрайзнутых функций. Плюс ко всему для ее нормальной работы нужно уж очень много приседаний — те же рефакторинги для простейших операций.
Во-вторых, насчет миграций в обе стороны. В бою, разумеется, назад редко когда мигрировать приходится, но в разработке подобная возможность очень и очень помогает. Поправил схему, пощупал, что она из себя представляет, не понравилось — откатил и начал заново.
Факты зашкаливают. Что именно там от "«блоатянки» и энтерпрайзнутых функций".
Какие рефакторинги для приседаний? Схема ведется в проекте полностью и при необходимости через Schema compare генерится скрипт обновления.
Версионность проекта позволяет так же двигаться в обе стороны, схема обновляется вообще в 3 клика, если с потерей данных при изменении — бэкапы проще и быстрее. можно перескочить на схему даже 2хлетней давности.
Есть и генераторы данных если очень хочется большую базу и сразу а не только схему.
Вы работали вообще с этой фичей студии и в каких версиях? Давайте все-таки оперировать фактами а не ощущениями и microsoft-ненавистью…
Какие рефакторинги для приседаний? Схема ведется в проекте полностью и при необходимости через Schema compare генерится скрипт обновления.
Версионность проекта позволяет так же двигаться в обе стороны, схема обновляется вообще в 3 клика, если с потерей данных при изменении — бэкапы проще и быстрее. можно перескочить на схему даже 2хлетней давности.
Есть и генераторы данных если очень хочется большую базу и сразу а не только схему.
Вы работали вообще с этой фичей студии и в каких версиях? Давайте все-таки оперировать фактами а не ощущениями и microsoft-ненавистью…
Хм. Напишу комент нищеброда.
Ну, начнем с того, что фича с Database Project доступна с версии Professional. Если не делать никаких приседаний, сама студия этой версии стоит где-то в районе 800 долларов.
Все бы ничего, но Database Project работает только для MS SQL 2005 — 2008. Поэтому, если вы разрабатываете код для\вместе с другой БД, то решение от МС вам не подойдет. Не подойдет вам это решение, если вы поставляете свое решение много раз — платить 2 штуки баксов за Standard Edition, ну, мягко скажем, тоже не с руки. Особенно если у вас стартап или нет стабильного инвестора.
Поэтому тулза рулит тем, что
а) она бесплатна
б) есть поддержка нескольких движков БД
ц) имеет все плюшки опенсорса и коммунити разработки
Из минусов решения отмечу, что оно не работает под моной, а стало быть непригодно для использования в linux-средах. Все таки, виндовый сервер стоит тоже недешево:)
Ну, начнем с того, что фича с Database Project доступна с версии Professional. Если не делать никаких приседаний, сама студия этой версии стоит где-то в районе 800 долларов.
Все бы ничего, но Database Project работает только для MS SQL 2005 — 2008. Поэтому, если вы разрабатываете код для\вместе с другой БД, то решение от МС вам не подойдет. Не подойдет вам это решение, если вы поставляете свое решение много раз — платить 2 штуки баксов за Standard Edition, ну, мягко скажем, тоже не с руки. Особенно если у вас стартап или нет стабильного инвестора.
Поэтому тулза рулит тем, что
а) она бесплатна
б) есть поддержка нескольких движков БД
ц) имеет все плюшки опенсорса и коммунити разработки
Из минусов решения отмечу, что оно не работает под моной, а стало быть непригодно для использования в linux-средах. Все таки, виндовый сервер стоит тоже недешево:)
Откат изменений может понадобиться в 2 случаях:
1. Пересоздание БД для модульных тестов
2. Откат на 1-2 версии назад, если возникла ошибка при выполнении изменений (например, она может быть связана с данными в конкретной БД).
На счет студии — Вы сможете сгенерить скрипт, который обновляет базу с одной конкретной версии до другой. Мигратор генерирует скрипты во время выполнения миграций и может, например, обновить БД с любой версии до последней.
Кроме того, мигратор содержит удобные средства выполнения миграций, которые можно легко использовать в т.ч. из своего приложения. Например, достаточно написать 2 строчки, чтобы при старте приложение само обновляло свою БД. Когда Вы пишете сайт, существующий в интернете в единственном экземпляре, Вы можете легко выполнить скрипты руками или написать себе bat-файл. Если же Вы пишете коробочный продукт, то с мигратором Вам будет значительно легче развернуть его у клиента.
1. Пересоздание БД для модульных тестов
2. Откат на 1-2 версии назад, если возникла ошибка при выполнении изменений (например, она может быть связана с данными в конкретной БД).
На счет студии — Вы сможете сгенерить скрипт, который обновляет базу с одной конкретной версии до другой. Мигратор генерирует скрипты во время выполнения миграций и может, например, обновить БД с любой версии до последней.
Кроме того, мигратор содержит удобные средства выполнения миграций, которые можно легко использовать в т.ч. из своего приложения. Например, достаточно написать 2 строчки, чтобы при старте приложение само обновляло свою БД. Когда Вы пишете сайт, существующий в интернете в единственном экземпляре, Вы можете легко выполнить скрипты руками или написать себе bat-файл. Если же Вы пишете коробочный продукт, то с мигратором Вам будет значительно легче развернуть его у клиента.
1. Пересоздание бд для модульных тестов — тут можно использовать и другие решения, помимо пересоздания бд.
2. Сложный сценарий — что даст откат схемы (или вы умеете «откатывать» чужие некорректные данные ?) на 2 версии назад если данные некорректны?
Версионность баз для клиента можно поддерживать через ту же цепочку скриптов миграции с версии коробочного продукта 1.0 -> 1.1 -> 1.5 -> 2.0. Собственно мне немного странно генерить скрипт обновления но не сохранять его. Цепочка скриптов — с любой до любой версии. Включая данные в определенном порядке (например в 1.5 данные добавились а в 2.0 они же — модифицировались или по ним произвели вычисления).
В коробочных продуктах миграции конечно сложнее, т.к. нет доступа к исходному состоянию и нет определенных инструментов на машине где развертывается продукт. И возможно именно для таких сценариев нужна более интеллектуальный механизм развертывания. Но не проще ли тогда создавать новую базу и просто переносить туда все данные (подходит естественно для малых бд) чем шаманить с соответствующими «миграциями»?
2. Сложный сценарий — что даст откат схемы (или вы умеете «откатывать» чужие некорректные данные ?) на 2 версии назад если данные некорректны?
Версионность баз для клиента можно поддерживать через ту же цепочку скриптов миграции с версии коробочного продукта 1.0 -> 1.1 -> 1.5 -> 2.0. Собственно мне немного странно генерить скрипт обновления но не сохранять его. Цепочка скриптов — с любой до любой версии. Включая данные в определенном порядке (например в 1.5 данные добавились а в 2.0 они же — модифицировались или по ним произвели вычисления).
В коробочных продуктах миграции конечно сложнее, т.к. нет доступа к исходному состоянию и нет определенных инструментов на машине где развертывается продукт. И возможно именно для таких сценариев нужна более интеллектуальный механизм развертывания. Но не проще ли тогда создавать новую базу и просто переносить туда все данные (подходит естественно для малых бд) чем шаманить с соответствующими «миграциями»?
1. Для модульных тестов — вариантов полно. Пересоздание БД — один из них. Он довольно удобен.
2. На счет скриптов, в принципе, Вы правы. Единственное, очень интересно, чем Вы обычно выполняете такую последовательность скриптов?
Я раньше участвовал в одном проекте, в котором каждую неделю прибавлялось по 10-20 таких скриптов. И их выполнение руками — был еще тот геморрой.
3. На счет создания новой БД и переноса данных — не очень себе представляю, как это происходит в автоматическом режиме у большого числа клиентов при установке обновления ПО.
2. На счет скриптов, в принципе, Вы правы. Единственное, очень интересно, чем Вы обычно выполняете такую последовательность скриптов?
Я раньше участвовал в одном проекте, в котором каждую неделю прибавлялось по 10-20 таких скриптов. И их выполнение руками — был еще тот геморрой.
3. На счет создания новой БД и переноса данных — не очень себе представляю, как это происходит в автоматическом режиме у большого числа клиентов при установке обновления ПО.
@2. 10-20 скриптов в неделю это сурово конечно. А объединять их в правильной последовательности в миграционный скрипт «неделька» невозможно было?
Мы сами выполняем SQL студией т.к. делаем проект для веба ;). Но вроде как sql.exe и прочие консольные радости выполнения скриптов достаточно распространены.
Мы сами выполняем SQL студией т.к. делаем проект для веба ;). Но вроде как sql.exe и прочие консольные радости выполнения скриптов достаточно распространены.
Вот к этому я и веду разговор. Мигратор все делает именно так, как Вы описали. Можете считать, что это bat-файл, который через sql.exe запускает скрипты, только его на порядок проще использовать.
На счет процесса написания скриптов: через GUI или в коде — задавать изменения БД в коде не так сложно, как Вы думаете. Даже если Вы создаете таблицы через GUI, Вам все равно нужно писать названия таблиц и полей, выбирать типы полей из выпадающих списков и т.д. По объему набираемого текста получается почти то же самое, по затрачиваемому времени — лично у меня получается писать код чуть быстрее.
Определение изменений БД в коде имеет еще одно преимущество: Вы контролируете непосредственно процесс изменения БД. Благодаря этому изменения БД становятся проще и надежнее.
На счет процесса написания скриптов: через GUI или в коде — задавать изменения БД в коде не так сложно, как Вы думаете. Даже если Вы создаете таблицы через GUI, Вам все равно нужно писать названия таблиц и полей, выбирать типы полей из выпадающих списков и т.д. По объему набираемого текста получается почти то же самое, по затрачиваемому времени — лично у меня получается писать код чуть быстрее.
Определение изменений БД в коде имеет еще одно преимущество: Вы контролируете непосредственно процесс изменения БД. Благодаря этому изменения БД становятся проще и надежнее.
Есть еще одно применение. Допустим есть плагин в CMS, который использует некую таблицу. Кто хотел установил этот плагин к себе на сайт, а при установке плагина автоматом создаются нужные таблицы.
Разработчик плагина меняет структуру таблицы и выкатывает вторую версию плагина. При этом в коде он пишет, что конкретно изменилось.
Когда пользователи устанавливают плагин, у них автоматом меняется структура таблиц.
По такому принципу работает миграция в Orchard CMS. Идея эта очень хорошая. Единственное там нет реализации отката, но там она просто не нужна.
Разработчик плагина меняет структуру таблицы и выкатывает вторую версию плагина. При этом в коде он пишет, что конкретно изменилось.
Когда пользователи устанавливают плагин, у них автоматом меняется структура таблиц.
По такому принципу работает миграция в Orchard CMS. Идея эта очень хорошая. Единственное там нет реализации отката, но там она просто не нужна.
Ага, специально для возможности контроля версий нескольких модулей внутри одной системы мы добавили ключи миграциям.
Теперь сборку с миграциями можно пометить атрибутом MigrationAssembly и указать для сборки ключ:
[assembly: MigrationAssembly(«test-key111»)]
Каждый плагин может указать для своих миграций собственный ключ и его изменения БД не затронут остальные остальные плагины.
Теперь сборку с миграциями можно пометить атрибутом MigrationAssembly и указать для сборки ключ:
[assembly: MigrationAssembly(«test-key111»)]
Каждый плагин может указать для своих миграций собственный ключ и его изменения БД не затронут остальные остальные плагины.
Очень полезно/удобно при выкатывании новых версий на тест/дев/ и прочие сервера особенно в сочентании с TeamCity и прочими тулсами
Огромное спасибо за апдейт, единственная проблема:
в списке «Loaded migrations» при выполнении миграций по-моему стоит делать упорядочивание по версии миграции, а не по её названию, а то тяжело воспринимать информацию:
в списке «Loaded migrations» при выполнении миграций по-моему стоит делать упорядочивание по версии миграции, а не по её названию, а то тяжело воспринимать информацию:
Migration key:
Loaded migrations:
33 Add blogs groups
25 Add blog view and comment counters
38 Add tags view
39 Alter blogs stats views
14 Blogs
41 Blogs content add
27 Blogs fix
18 Blogs moderate add
19 Blogs url add
10 Change profiles
8 Change site settings
42 Change site settings
20 Comments
21 Comments fix
16 Friends
13 Friends
3 Mail system
1 Membership roles
30 Modify blogs
31 Modify blogs and rights
23 New blogs
12 P m groups add
32 P m groups modify
9 P m system
28 Private blog requests
6 Profiles
4 Profiles
35 Recreate tags
34 Set blogs uniq
2 Site settings
11 Static content
24 Static content add
22 System blogs
29 System blogs add
26 Tags add
7 Temporary tokens
5 Temporary tokes
36 Update blog posts content
40 Update comments
37 Update tags
17 Users activity
15 Users activity
А вы планируете добавить Firebird в список поддерживаемых СУБД?
пока не планировали, но если нужно добавить — это будет не сложно
главная проблема — найти того, кто реально использовал бы провайдер для Firebird: не очень хочется добавлять в проект функционал, который мы не можем протестировать в реальных условиях
главная проблема — найти того, кто реально использовал бы провайдер для Firebird: не очень хочется добавлять в проект функционал, который мы не можем протестировать в реальных условиях
Вот тут спрашивали. Я рекомендовал Ваш проект, но жаль что, да, пока без поддержки FB «из коробки». У самого на FB проект небольшой, пока резона использовать в этом проете Вашу разработку не вижу. А вот люди, да, интересуются.
Добрый день!
Сейчас идет активная работа над третьей версией мигратора. В ней будут провайдеры для Firebird и SQL Azure.
Также будут большие изменения в базовом классе провайдеров и будут написаны новые тесты для провайдеров — все это значительно облегчит написание собственных провайдеров для любых дополнительных СУБД.
Думаю, мы закончим версию 3.0 в течение месяца.
Сейчас идет активная работа над третьей версией мигратора. В ней будут провайдеры для Firebird и SQL Azure.
Также будут большие изменения в базовом классе провайдеров и будут написаны новые тесты для провайдеров — все это значительно облегчит написание собственных провайдеров для любых дополнительных СУБД.
Думаю, мы закончим версию 3.0 в течение месяца.
SQL Azure не поддерживается?
Пока не поддерживается, но есть в ближайших планах (сейчас пишем приложение для облака и в ближайшие 2-3 месяца нужно будет его туда выкладывать).
Сейчас получил тестовый доступ к SQL Azure и прогнал тесты. Оказалось, что все не так страшно :)
Постараюсь добавить поддержку SQL Azure в течение 1-2 недель.
Кстати, если нужен тестовый доступ, его раздают здесь (данные живут в облаке 24 часа, тестовый доступ можно запрашивать сколько угодно раз).
Постараюсь добавить поддержку SQL Azure в течение 1-2 недель.
Кстати, если нужен тестовый доступ, его раздают здесь (данные живут в облаке 24 часа, тестовый доступ можно запрашивать сколько угодно раз).
Добавлена поддержка SQLAzure.
Теперь вместо двух диалектов «SqlServer» и «SqlServer2005» есть только один диалект «SqlServer», который поддерживает MSSQL 2005, 2008, 2008R2 и SQL Azure. Поддержка MSSQL 2000 удалена.
Если напишете мне Вашу почту, пришлю новую версию мигратора. Ну… или можете сами собрать из исходного кода (там есть build-файл для NAnt).
В ближайшее время сделаем еще несколько доработок и выпустим версию 2.0.1
Теперь вместо двух диалектов «SqlServer» и «SqlServer2005» есть только один диалект «SqlServer», который поддерживает MSSQL 2005, 2008, 2008R2 и SQL Azure. Поддержка MSSQL 2000 удалена.
Если напишете мне Вашу почту, пришлю новую версию мигратора. Ну… или можете сами собрать из исходного кода (там есть build-файл для NAnt).
В ближайшее время сделаем еще несколько доработок и выпустим версию 2.0.1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграции БД для .NET