Насколько хороша BuildSchema от NHibernate?

Question

Я недавно смотрел на NHibernate и пытался изучить все входы и выходы. В нескольких статьях я заметил одну вещь - использование BuildSchema для создания тестируемой базы данных.

В конкретном примере в качестве базы данных использовался SqlLite. Можно ли доверять BuildSchema при создании вашей базы данных или все же лучше всего создать собственную схему базы данных стандартным способом? В моем случае используется SQL Server Management Studio.

Обновление: Оба ответа, кажется, дают верный совет, я бы не сказал, что у этого вопроса есть «ответ», поэтому я не буду отмечать один конкретный ответ как окончательный. Однако я проголосовал за вас обоих за ваш совет.

Общая идея, по-видимому, заключается в том, чтобы использовать BuildSchema на ранних этапах разработки до того, как дизайн базы данных установится, а затем перейти к созданию / изменению сценариев SQL при использовании контроля версий.

Answer 1

Пытаясь максимально приблизиться к методологии проектирования, ориентированной на домен, я использую NHibernate для построения своей схемы во время разработки. Как только приложение достигло некоторого уровня стабильности (отток модели домена значительно замедлился) или был достигнут важный этап, я переключаюсь на метод К. Скотта Аллена, который обсуждается в его блоге.

K. Статьи Скотта Аллена в блоге о версиях схемы базы данных

Ash Tewari внедрил систему mgmt скриптов изменений, которая использует NHibernate, основанную на статьях Аллена об этом.

Ash Tewari's DbUpdater

Answer 2

К началу проекта может оказаться практичным иметь схему, сгенерированную BuildSchema, но как только вы заработаете с некоторой критической массой (или если вы что-то выпустили для других), вам нужно координировать изменения в коде изменения в схеме. Это не работает с методом buildschema.

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

Каждый сценарий является собственным файлом и может содержать более одного изменения в DDL и / или DML для переноса данных и т. Д.

Мы действительно используем понижения только тогда, когда есть изменения, которые будут несовместимы с предыдущими версиями (это редко встречается в наших проектах).