我们正在参与一项新的发展，我们正在重建当前的网上商店平台。 在当前平台中，我们不使用EF6和其他ORM，而是使用存储过程访问数据库，但在新建筑中我们就是这样做。
我们对新平台的数据库设计存有疑问。在当前平台中，我们根据它们的内容使用几个不同的数据库。 例如，我们有专门的数据库来存储产品目录的信息，其他专用数据库用于处理订单。 目前，所有数据访问都是通过存储过程完成的，因此我们对不同数据库之间的链接没有任何问题。 当我们开始使用EF6时，问题就出现了。在这种情况下，每个DB与上下文相关联，并且不可能知道从一个上下文到另一个上下文的数据 除非我们使用各种上下文直接在源代码中实现这些关系。看起来这意味着我们将失去EF6的力量。
我们遇到的问题是： 使用EF6为同一应用程序维护不同的数据库是不是很糟糕？ 如果这是一个糟糕的设计并选择单个数据库，那么即使用几TB信息驱动数百个表（几乎1000个），性能也会达到最佳状态？ 另一方面，在选择出现几个bbdd的设计的情况下（在我们的情况下它会好得多），处理EF6的最佳方法是什么？
非常感谢你的帮助！
答案 0 :(得分：1)
首先，EF不是编写为跨数据库的。你不能写跨数据库（交叉上下文）查询，延迟加载不起作用等等。 在您的情况下，这是一个很大的限制。 EF可以使用多个模式（实际上我不使用它，我不喜欢它，但只是我的意见）。
您可以将您的存储过程与EF一起使用，但据我所知，您正在考虑停止使用它们。
根据我的经验，我使用多个数据库编写了多个应用程序，但使用不同的数据库非常有限。在这种情况下，我使用跨数据库视图（即每个公司一个数据库和一些公共表，其中公司数据库中的视图选择公共表中的数据）。在您的情况下，如果表格在任何地方都是分片的，我认为这不是您可以选择的方式。
所以，在我看来，你可以改变方法 如果你有备份问题，你可以分割大表（我认为事实表和带有图片的表）并创建跨数据库视图。同样，在SQL Server中不支持跨数据库引用完整性，因此您需要编写触发器来检查它 如果您需要拆分不同的应用程序功能（即WMS，CRM等），您可以使用名称空间，而无需担心表格如何存储在数据库中。