Я хочу уточнить свой рабочий процесс вокруг NHibernate и относительно часто меняющуюся схему, и как лучше всего справиться с этим - я хотел бы, чтобы одно и то же решение применимо к производственным системам, поэтому я думаю, что мне нужен механизм миграции, а не просто обновление схемы.
Что я хочу знать, так это то, как я могу как можно лучше доработать рабочий процесс, чтобы как можно меньше работать, чтобы синхронизировать мою базу данных с моей моделью домена. Подход сценариев к тарантино выглядит неплохо, но, похоже, не существует способа генерировать обновление script из моих сопоставлений nHibernate, поэтому я могу скомпоновать создание script или используя инструмент reddate sql compare, подобный инструменту, Есть ли что-то, что мне не хватает, что облегчит жизнь вокруг этапа генерации script?
Спасибо, Крис
Я не использовал ни один из этих инструментов миграции для .net самостоятельно, но когда вы пытаетесь запустить Ruby on Rails в свое свободное время, лет назад я видел преимущества миграции по сравнению с сценариями t-sql, которые мы использовали на моей работе в то время.
В недавнем проекте, который я видел, мы обнаружили, что миграции в сочетании с ветвлением VCS и NHibernate могут вызывать несколько головных болей и недостатков на этом пути.
Мы создали NHibernate для создания схемы с каждой автоматической сборкой (для среды разработки) наряду с некоторой загрузкой данных.
В производственной среде у нас был script, основанный на текущей схеме и желаемой схеме, он сгенерировал одну миграцию с необходимыми полями и изменениями.
Мы используем SQL Compare. Он оплачивается, но стоит инвестиции imho. Храните каждый из сгенерированных скриптов хорошо организованным - то есть timestamped - и вы получите хороший способ генерации базы данных для любой из выпущенных версий.
Это наш обычный поток
Посмотрите параметры командной строки, поскольку они весьма удобны для автоматизации процесса с помощью событий сборки VS.