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

Question

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

由于我们正在使用实体框架，任何跨数据库查询都证明是一个真正的痛苦，我们已经尝试了许多不同的方法，我个人认为主要的问题是EF实际上并不适用于多个数据库。 / p>

虽然我知道答案通常是“取决于”我对这个人的想法或观点感兴趣所以真正的问题是

1. 我们是否应将所有单独的数据库合并为一个大型数据库？

2. 将数据拆分到不同的数据库是否正确（即使EF不能很好地使用它）？

Answer 1

你说

  

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

然后

  

交叉数据库查询证明是一种真正的痛苦

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

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

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

Answer 2

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

你猜对了的答案很可能是“它取决于”。但在这里我会说不，分裂可能不是一个正确的选择。 如果您不得不进行跨数据库查询，则很可能数据拆分不正确。在数据独立的某些情况下分割数据库可能会更好 - 例如，事务和报告（但当然需要从一个数据同步到另一个数据库）。

您是否考虑过在同一个数据库中分离数据，但是它们位于不同的模式中？这就是通常所做的事情。