Я установил систему, в которой я взял первый подход к модели, поскольку для меня это стало более логичным. Теперь, когда даже у меня есть некоторые изменения в модели, в настоящее время я делаю это -
Вопрос. Основная проблема заключается в том, что это действительно утомительно, и поскольку я делаю это из своей локальной системы, подключение к моим базам данных prod происходит очень медленно, и иногда моя визуальная студия также падает. Есть ли более чистый подход для этого? Что более автоматизировано, так что мой ноутбук не несет ответственности за миграцию базы данных на экземплярах производства?
Вы можете попробовать Пакет миграции базы данных - он позволяет создавать сценарии изменений вместо полных сценариев базы данных, но позади него выполняет ту же процедуру, что и вы сделал вручную. Проблема в том, что упомянутый инструмент не работает с EF5.
К сожалению EF migrations в настоящее время не поддерживают модели, созданные с помощью EDMX. Миграции поддерживают только первый подход к коду в настоящий момент.
В первой схеме схемы я использую ApexSQL Diff (вполне вероятно, очень похож на продукт RedGate, возможно, немного дешевле) - хороший сторонний инструмент намного проще в использовании, чем VS Database Project, и его легко применять с помощью script -приложения, такие как RoundHousE.
Используя его в подходе модели First, можно следовать методу Schema First, используя цикл Model-Schema-Diff-Schema-Model, как описано в сообщении; рассмотрите приведенные ниже руководящие принципы/примечания для упрощения процесса. Подход схемы-diff не должен быть утомительным, медленным или чрезмерно ручным.
Текущая версия схемы базы данных получается путем применения последовательности патчей базы данных (или сценариев DDL/DML).
Инструмент (мы используем RoundHousE) автоматически применяет скрипты по мере необходимости. Он записывает информацию, чтобы знать, какие скрипты были применены. Применение одинаковых сценариев является идемпотентным.
Diff, выполненный против локальной базы данных; эта локальная база данных может быть создана из всех предыдущих сценариев изменений в автоматическом режиме. Это последнее локальное значение всегда является целью сравнения для последних изменений модели.
Удаленная/живая база данных никогда не используется как цель diff. Те же самые сценарии могут быть применены позже к тестовым (а затем и живым) базам данных. Поскольку все делается одинаково, процесс повторяется во всех базах данных.
Единственная проблема заключается в том, что обновление, которое не очень хорошо продумано, может привести к недопустимым данным при новых ограничениях/ограничениях. Конечно, это было легко идентифицировать, исправлять и повторно различать, прежде чем вживаться в живую базу данных.
После того, как diff используется для управления источником, он должен применяться к ветке. Чтобы "отменить" ранее зафиксированное изменение - script, требуется создать новый diff, применяющий обратное действие. Нет неявной понижающей версии.
У нас есть ветвь модели [Hg], которая аффективно действует как блокировка схемы, которая должна быть объединена против; это можно рассматривать как слабый момент, но он хорошо справился с развитием небольшой команды.
Инструмент, такой как Huagati DBML/EDMX, используется для синхронизации схемы с моделью, которая действительно полезна при разработке. Эта маленькая жемчужина действительно платит за себя и является частью цикла. Когда это используется, легко также "обновить модель" или внести изменения схемы в SSMS (или что-то еще), а затем вернуть их обратно.
Первыми миграциями кода являются "ОК" (и, безусловно, лучше, чем ничего!), но я использую их только потому, что Azure SQL (так называемая база данных SQL) не поддерживается расширенными инструментами diff из-за того, что не подвергается различной информации sys. (Дифференциалы могут выполняться локально в соответствии с нормальным, но ApexSQL Diff генерирует DDL/DML, который не всегда дружит с Azure SQL - plus, это шанс для меня изучить несколько иной подход: -)
Некоторые преимущества миграции кода First через Power Pack: могут выполнять задачи обновления на С#, а не ограничиваться DDL/DML (может быть удобно), автоматическое понижение (хотя я сомневаюсь в их использовании), не нужно покупать сторонний инструмент (может быть дорогостоящим), упростить интеграцию/развертывание в Azure SQL, менее привязан к конкретному поставщику базы данных (теоретически) и т.д.
В то время как миграции кода First (и автоматизация таких) являются хорошим шагом вперед против абсолютно ужасного подхода Drop-and-Recreate, я предпочитаю выделять инструменты SQL при разработке.