SQL Server数据工具和实体框架-这里有协同作用吗？

从使用Linq2Sql进行的一个项目中，我怀疑下一个（更大）的项目可能会将我推入Entity Framework的怀抱。我已经对该主题进行了一些阅读，但是我没有找到一个连贯的故事，关于如何/应该/可能将SQL Server数据工具和实体框架一起使用。

• 它们是完全分开构想的，并且一起使用会产生错误的结果吗？
• 它们是否完全正交，我错过了要点？

我认为我可能同时想要这两个原因：

• SSDT非常适合“编译”（检查）且易于版本控制的sql和schema
• 但是，SSDT的“迁移/更新”故事（在我看来）并不令人信服：“更新任何内容”对于架构都可以，但是（AFAIK）绝不可能对数据起作用。
• 另一方面，我还没有尝试过EF迁移来了解它是否存在类似的问题，但是Up / Down位看起来非常方便。

让我提出另一种观点。在任何企业或大型数据库项目中，实体框架数据库维护完全没有用。

问题是：

• 自动模式更新。这绝对不是我想要的，因为它完全违反了数据库维护的基础。问题是：（a）运行新版本的人更新数据库而不是出现问题；（b）dba安排了更新，通常首先进行备份。因此，自动更新是没有用的。

• DB创建仅适用于基本退化的边缘情况。甚至不要尝试使用高级数据库功能-不管哪一个。SQL Server示例：索引中包含的字段，索引过滤器，分区，压缩，字段的验证规则。

• 迁移-再次假设边缘情况恶化：不容易进行数据转换或多步骤更新。示例：表X具有一个历史“用户”字段，该字段记录用户所做的事情。新设置有一个用户表，因此需要创建用户表，然后创建用户，然后在表x中创建用户引用字段，然后使用用户表中的用户对其进行更新，然后删除用户字段。

处理这些情况的唯一明智的方法是生成和迁移脚本以及正确的版本控制。

现在，SSDT（这是用于对特定数据库版本进行版本控制的好工具，因为它实际上比Entity Framework好得多）。如图所示：它记录了所有功能。在没有任何一个数据库的情况下，我几乎可以先使用代码-因为我们始终至少已过滤索引；）EF甚至无法达到我所需要的10％。

我们的方法是：

• 在数据库中设计数据库，然后向下同步到被检入的SSDT模块。模式同步允许开发人员快速更新其版本。总会有一个权威的主数据库，其当前版本位于某个特殊服务器上的某个位置（因此，在特殊服务器上），因此我们需要一个参考版本。

• 根据发行版的需要生成增量脚本，这些脚本也会获得版本控制，并具有将其部署到数据库的良好机制。

将EF与SQL Server数据库一起使用的方法不止一种。

1. 代码优先...编写类，EF生成关联的表
2. 首先使用数据库...设计表，然后EF生成类。

EF不一定会为您完成所有工作。EF将为您带来80％到95％的收益。数据库开发工作的其余5％到20％将通过视图和存储过程之类的优化得到补充。

所以不，它们不是正交的。但是，您必须决定总体设计策略，然后依靠SSDT之类的工具来帮助您优化EF产生的效果不理想的零件。