我们的团队正在考虑利用Entity Framework Core代码优先帮助建模数据库。我们可以同时拥有数据库项目和EF模型，根据文章Database Projects vs. Entity Framework Database Migrations利用模式比较，只是想弄清楚什么是真相的来源？
Entity Framework是否支持SQL Server SSDT数据库项目中的所有功能？
EF Core 2不支持哪些功能？ （例如，它是否不支持以下任何内容：触发器，视图，函数，存储过程，加密密钥，证书，db属性（ansi null，带引号的标识符），分区）
我正在尝试找到Microsoft资源。
tl; dr数据库项目功能丰富，但数据库优先。迁移是代码优先的，但具有非常有限的内置数据库功能集。
对于许多人来说，比较数据库项目和迁移是没有意义的。它们代表了与Entity Framework一起使用的两种不同模式。迁移是代码优先的，DP是数据库优先的。当然，您可以使用迁移来控制数据库模式，并使DP与生成的数据库保持同步以满足DBA（如链接所示）。但两人都过着独立的生活，而且没有Single Source Of Truth。
因此，如果你不确定你将选择哪种工作模式，那么比较它们会非常有用。
对我来说，最重要的区别是DP将覆盖所有数据库对象，并在比较数据库时检测它们之间的所有变化。迁移仅检测数据库和映射模型之间的更改。用于生成数据库对象的选项集非常有限。除了您需要的一切，您还必须将SQL语句注入迁移代码。这些陈述是您自己的责任。如果迁移需要ALTER PROCEDURE语句（例如），你必须弄清楚自己。如果脚本和数据库在这方面不同，EF不会抱怨。
这是我从未成为移民狂热粉丝的主要原因。维护成熟的数据库架构几乎是不可能的，包括存储，文件组，权限，归类以及您拥有的内容。
DP的另一个优点是它们与源控制相结合非常好。每个数据库对象都有自己的文件，很容易检查每个对象的更改历史记录。生成的迁移无法实现这一点。实际上，许多中间变化可能永远不会成为生成的迁移。
当然，迁移的明显优势是可以对代码和数据库是否匹配进行运行时检查（尽管不完整）。在数据库优先项目中，您需要为此创建自己的机制。
EF Core只是ORM。
1）您应该准备好手动创建除表之外的所有数据库对象。我手动创建的内容：constrates（默认值和条件）。由于这是代码优先 - 在SP，函数等中不需要。如果使用ORM - DB只是存储。当然，练习很重要。对我来说，默认约束可以为我手动创建测试数据的表增加舒适度。在您不信任（团队）代码的情况下，条件也很有用。
2）你将在普通的sql中创建（和删除）视图，触发器，sp等等“迁移”代码（在EF中有这样的概念）：
migrationBuilder.Sql("CREATE VIEW ...");
因此，您可以使用单独的“迁移”程序（例如命令行工具）来安装或删除Ef Core表和手动创建的对象，执行并还原数据迁移。
“EF核心迁移”是一个相当复杂的API（预留一周学习）。有趣的话题：在一个数据库中管理多个dbcontexts，在从模型注释迁移期间创建数据库对象，unistall。或者找一个自由职业者（项目的这一部分适合外包）。