Sql server 使用EF的多个SQL数据库-设计好还是坏？

目前，我们有一个大型的内部平台，它使用了许多不同的SQL数据库（都在同一台服务器上）。我们总是创建新的数据库，在这些数据库中，我们感觉数据与我们存储在其他数据库中的数据完全不同/独立。通过这种方法，我们最终拥有了许多不同的数据库（大多数都有30-50多个表），但它们之间不可避免地需要一些连接

当我们使用实体框架时，任何跨数据库查询都是一个真正的难题，我们尝试了许多不同的方法，我个人认为主要的问题是EF不能真正跨多个数据库工作

虽然我知道答案通常是“视情况而定”，但我对人们的想法或观点很感兴趣，所以真正的问题是

我们是否应该将所有单独的数据库合并到一个大型数据库中

将数据拆分为不同的数据库是正确的（即使EF不能很好地使用它）

---

你说的数据库有多大？多少个表/多少GB？进入的数据类型是什么

你猜的答案很可能是“视情况而定”。但在这里我要说不，分裂可能不是一个正确的选择。 如果必须进行跨数据库查询，则很可能是数据拆分不正确。在某些数据独立的场景中，如事务和报告（当然，这需要从一个数据库到另一个数据库进行数据同步），跨数据库拆分可能会更好

您是否考虑过在同一个数据库中分离数据，但驻留在不同的模式中？这是通常的做法。

你说

我们认为数据与我们存储在其他数据库中的数据完全不同/独立

然后

事实证明，跨数据库查询是一个真正的难题

如果您必须执行许多跨数据库查询，那么数据可能不像您想象的那样独立，在这种情况下，合并数据库可能更有意义

另一方面，如果跨数据库查询很少，那么它可能是正常的。如果不知道域模型的详细信息以及每个数据库中包含的内容，就很难说了。检查进行这些跨数据库查询的情况，并查看进行这些查询的原因以及这种情况发生的频率。如果重要或频繁，那么考虑合并。如果这种情况很少见，或者不是性能关键型的，或者合并数据库的麻烦远远超过编写这几个跨数据库查询的麻烦，那么这种情况可能很好。但要注意最后一点——现在分开数据库可能更容易，但将来可能会遇到一些在合并数据库上更容易的问题。再看一看这些数据库中存储的数据类型，列出可能需要跨数据库查询的所有场景。然后查看这些场景中的每一个，并确定发生这种情况的可能性，以及如果不合并数据库，会造成多大的问题。这将帮助您决定是否合并

---

如果您决定合并，请尽快合并。没有合并的每一天都是人们编写代码的日子，当你着手进行合并时，这些代码必须被重构。您越早这样做，就越容易。

对于数据量较大的数据库，其大小不是5-10GB，而对于其他数据库，则小于1GB。数据密集型数据库倾向于存储市场数据系列，例如DateTime和Values。虽然每个dbI（30-50个）都有很多表在使用，但它们肯定会使用模式—更易于管理，跨环境保持同步。除非你的分贝大小达到100Gbs（即使这样也可以），否则你应该尝试移动到一个分贝，以使你的生活更轻松。对不起，但是…这取决于。）有多大？每个数据库中要处理多少个表？一共有多少？您可以在每个数据库中定义调用其他数据库的视图，并构建使用它们的实体。我通常建议不要分离数据，除非这是很少甚至没有交叉通信的。通常模式更适合分割数据。您可以尝试在“MainDatabase”上使用可更新视图，该数据库将视图写入其他数据库。我不知道EF是否能很好地处理可更新视图。我认为大多数人编写存储过程是为了在使用可更新视图时使用EF。但这是一个你可能想研究的想法。