Комментарии 11
Мой опыт использования миграций EF и EFCore показывает что применение миграций к БД непосредственно из основного приложения рано или поздно приведёт к проявлению граблей. Имеет смысл написать отдельную утилиту для менеджмента БД. И в ней уже проводить миграции, чистку, заполнение исходными данными. А основное приложение должно "падать" в случае проблем с БД.
Если уж решение требует использования миграций в основном приложении, то, опять же, опыт показывает, что EFCore в процессе создания новой миграции должна использовать свои стандартные механизмы для формирования объекта контекста БД по средствам либо:
- метода CreateHostBuilder в классе точки входа;
- реализации интерфейса IDesignTimeDbContextFactory.
в файле design.cs хранится снапшот на момент применения миграции. После отката миграции файл снапшот заменяется содержимым файла дизайн для предпоследней миграции (последняя же удаляется). Уменьшить его нельзя. Однако, если у вас очень большая БД, вы можете рассмотреть вариант разделения контекстов.
Например, контекст пользователей, контекст товаров и контекст заказов. Конечно, в этом случае использование данных будет отличаться. У вас уже не будет связи от сущности заказ к сущности пользователь (только по идентификатору), а значит вы не сможете в один запрос найти заказы всех пользователей с именем Иван. Но зато у каждого контекста будут свои миграции.
Бесит это переименовывание столбцов, кучу ручной возни тащит за собой, когда переименовывание не нужно, а нужно один удалить, а другой добавить. Вот почему бы в команду создания миграции не добавить ключ, запрещающий переименовывание?
Нюансы при работе с EF миграциями