Какие функции SQL Server 2017 сначала не поддерживаются в коде Entity Framework Core?

tl;dr Проекты баз данных многофункциональны, но в первую очередь ориентированы на базы данных. Миграции — это прежде всего код, но они имеют очень ограниченный набор встроенных функций базы данных.

Для многих людей не имеет смысла сравнивать проекты баз данных и миграции. Они представляют два разных режима работы с Entity Framework. Миграции — это прежде всего код, DP — это база данных. Конечно, вы можете использовать миграции для управления схемой базы данных и, кроме того, синхронизировать DP с созданной базой данных, чтобы удовлетворить требования администраторов баз данных (как следует из ссылки). Но оба ведут свою собственную жизнь, и не существует Единого Источника Истины.

Так что сравнивать их полезно, если вы еще не уверены, какой режим работы вы собираетесь выбрать.

Для меня наиболее важным отличием является то, что DP будет охватывать все объекты базы данных и обнаруживать все изменения между ними при сравнении баз данных. Миграции обнаруживают только изменения между базой данных и отображаемой моделью. И набор опций для генерации объектов базы данных очень ограничен. Для всего, что вам нужно дополнительно, вы должны ввести операторы SQL в код миграции. Эти заявления являются вашей собственной ответственностью. Вы должны выяснить сами, нужна ли миграция инструкция ALTER PROCEDURE или нет (например). EF не будет жаловаться, если сценарий и база данных будут отличаться в этом отношении.

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

Еще одним преимуществом DP является то, что они отлично сочетаются с системой контроля версий. Каждый объект базы данных имеет свой собственный файл, и очень легко проверить историю изменений каждого отдельного объекта. Это невозможно с сгенерированными миграциями. Действительно, многие промежуточные изменения могут никогда не попасть в сгенерированную миграцию.

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

EF Core — это только ORM.

1) Вы должны быть готовы создать все объекты БД, кроме таблиц, вручную. Что я создаю вручную: констраты (по умолчанию и условия). Так как это код в первую очередь - нет необходимости в SP, функциях и т.д. Если вы используете ORM - БД - это только хранилище. Конечно, практика важна. Для меня ограничения по умолчанию добавляют удобства в таблицах, где я создаю тестовые данные вручную. И условия также полезны в ситуациях, когда вы не доверяете своему (командному) коду.

2) вы будете делать создание (и удаление) представлений, триггеров, sp и т. д. в код "миграции" (такое понятие есть в EF) в обычном sql:

 migrationBuilder.Sql("CREATE VIEW ...");

В результате у вас может быть отдельная программа «миграции» (например, инструмент командной строки), которая устанавливает или удаляет как таблицы Ef Core, так и созданные вами вручную объекты, выполняет и отменяет миграцию данных.

«EF Core migrations» — довольно сложный API (зарезервируйте неделю для изучения). Интересные темы: управление несколькими dbcontexts в одной db, создание объекта db во время миграции из аннотаций модели, удаление. Или найдите для этого фрилансера (эта часть проекта хороша для аутсорсинга).