Миграция схемы/данных для SQL Server
От: kr0m Австралия http://sandheap.info
Дата: 06.08.10 05:35
Оценка:
Добрый день,

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

Наверное ближайшая аналогия это South из django (http://south.aeracode.org/) или то как реализованы миграции в RoR.

Задавал этот вопрос на SO (http://stackoverflow.com/questions/2596826/database-migrations-for-sql-server) и не могу сказать что удовлетворен предложенными вариантами.

Заранее спасибо.
Артем
Sine ira et studio
sql-server migrations
Re: Миграция схемы/данных для SQL Server
От: ZAMUNDA Земля для жалоб и предложений
Дата: 06.08.10 09:07
Оценка:
Здравствуйте, kr0m, Вы писали:

K>Добрый день,


K>Стоит задача управления изменениями, вносимымы в базу данных, включая как схему так и собственно данные.

По схеме уже обсуждалось. В TFS народ рассказывал есть AddOn на эту тему.

K>Ищется готовое решение, пригодное для работы как в команде, где много лбдей одновременно меняют структуру базы, так и в ситуациях когда люди с нескольких проектов работают с одной и той же схемой базы.

Я всю схему сохраняю в виде набора текстовых скриптов: скрипты создания таблиц/отношений/ограничений/индексов + исходники хранимок/функций/видиков/триггеров. Потом всё это складывается в CSV по вкусу, вешается JOB на автоперегенерацию скриптов, и делается "кнопка" на перегенерацию вручную. Ну там ещё фильтры, чтоб "чужие" хранимки не трогать, правда пока я это не реализовывал.

С данными не заморачивался — не требовалось. Вообще с трудом представляю как делать контроль изменения данных: это ж какие объёмы должны быть!!!
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Re[2]: Миграция схемы/данных для SQL Server
От: kr0m Австралия http://sandheap.info
Дата: 06.08.10 10:30
Оценка:
ZAM>С данными не заморачивался — не требовалось. Вообще с трудом представляю как делать контроль изменения данных: это ж какие объёмы должны быть!!!

Да, это не все данные, надо уточнить — это для статических данных, типа классификаторов, наборов описания различных статусов и п.р.

А
Sine ira et studio
Re: Миграция схемы/данных для SQL Server
От: Slava Vdovichenko США http://www.branegy.com
Дата: 06.08.10 23:11
Оценка:
Здравствуйте, kr0m, Вы писали:

K>Добрый день,


K>Стоит задача управления изменениями, вносимымы в базу данных, включая как схему так и собственно данные.

K>Ищется готовое решение, пригодное для работы как в команде, где много лбдей одновременно меняют структуру базы, так и в ситуациях когда люди с нескольких проектов работают с одной и той же схемой базы.

K>Наверное ближайшая аналогия это South из django (http://south.aeracode.org/) или то как реализованы миграции в RoR.


K>Задавал этот вопрос на SO (http://stackoverflow.com/questions/2596826/database-migrations-for-sql-server) и не могу сказать что удовлетворен предложенными вариантами.


Артём, думаю эта задача общая для многих разработчиков и администраторов.
У меня предварительные вопросы: чем не устраивают предложенные варианты (South, RoR, вроде как open source и можно коллективно доработать)?
Как будет выгдядеть идеальный процесс в вашей команде?

Слава
Re[2]: Миграция схемы/данных для SQL Server
От: kr0m Австралия http://sandheap.info
Дата: 07.08.10 05:04
Оценка:
SV>(South, RoR, вроде как open source и можно коллективно доработать)?

South устраивает всем, кроме того что проектов несколько, все на .NET, и разной степени давности.
Sine ira et studio
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.