使用多个数据库与使用单个数据库的利弊

我正在一个新项目中工作，该项目要求使用7个数据库，并认为更容易实现性能，稳定性和优化。

虽然我不同意，但我在收集好的参数以使用单个数据库时遇到了麻烦（将表拆分为逻辑域）。

到目前为止，我有一个论点是数据完整性（我不能在数据库之间使用外键）。

使用单个或多个数据库有哪些优点/缺点？

[到目前为止的总结]

针对多个数据库的参数：

• 丢失数据完整性（不能在数据库上使用外键）

• 失去还原完整性

• 获得复杂性（数据库用户/角色）

• 小赔率服务器/数据库将关闭

解决方案：

• 使用架构来分隔域。

• POC：使用伪数据证明7/1 db执行计划中的重点

性能，稳定性，优化都不是真的。有没有人有扎实的论点或参考文章为什么这些说法是正确的？

资源没有分配给数据库：SQL Server实例平衡资源，因此没有区别

你输了：

• 数据的完整性
• 恢复完整性（DB7中的数据将晚于DB1）

您会变得很复杂：

• 安全性（用户，角色等）必须位于所有数据库中
• 您将拥有一些不太适合1个数据库的数据

选项：

• 可以使用文件组将数据库拆分到单独的磁盘上
• 使用模式在逻辑上分离数据（基于其他答案）

创建单独的数据库的充分理由是为了支持不同的可用性要求或简化管理。例如，如果您的数据库需要非常不同的备份计划或不同的恢复模型。另一个原因是，如果您想在不同的实例上运行它们。

多个数据库没有性能优化，而一个数据库也无法实现。您能否详细说明“性能，稳定性，优化”的含义？

如果您要按逻辑域划分数据，则可以随时查看在SQL2008中使用架构的方法（这与dbo的默认设置不符）。但这甚至很痛苦，并且可能会导致OR / M出现意外问题-标准架构。

我一直在整理来自多个数据库的数据，这很痛苦而且远非高性能。您最终将缓存数据或至少使用技巧来保持速度。

作为测试，构建7个虚拟数据库。建立一个查询，该查询同时需要全部7个（或至少其中7个）的数据。

然后比较执行计划！我想您会在这里胜诉。

思想实验：不要将数据库分成七个部分，而是将其分成7,000个部分。硬件故障会影响您的应用程序的可能性有多大？如果某个特定服务器在特定日期可能会死掉0.1％的可能性，那么增加依赖的计算机数量时受到硬件故障影响的机会是好是坏？

我认为将“数据库”的概念分为两​​部分很重要：模式和数据与用于服务数据的硬件。

由于本主题中其他答案所解释的多种原因，在多台计算机上断开数据库不利于您。

如果您打算使用多台计算机来提高可靠性和增强性能，则可以对它们进行结构化，以便您的主服务器具有多台热/热备用计算机，也可以用于在其中分布查询。这样，如果任何一台计算机出现故障，就不会丢失任何数据，并且在最坏的情况下，您将不得不重新启动查询。当然，它比这更复杂，但是基础确实适用。

我同意一个数据库，而是使用文件和架构选项。

在某些情况下，将多个部分拆分是有意义的。

应用程序环境（开发，测试，生产）配置（例如FTP服务器，导出文件路径等），要在每个服务器上存储的东西，并且在还原时不会被覆盖。

这也是隔离客户端特定过程更改的一种方法。

但是这些是支持而不是性能问题。