多个数据库与具有逻辑分区数据的单个数据库

Question

我在思考数据库设计问题。任何帮助都将受到高度赞赏。

我们正在设计一个具有20个表格的应用程序（在新功能开发期间可能会增长到最多约30个）

技术堆栈

MVC4，.NET 4.X，实体框架5，SQL Server 2012，ASP.NET成员资格框架

用户数

我们打算迎合大约1000名平均有20位用户的客户。

问题

我们是否应该以对逻辑分区的方式设计数据库和应用程序，即所有客户端使用带有分区guid的相同表来分隔数据。

OR

转到多个数据库，这些数据库在新功能启动和错误修复期间可能会很难实现。但是可能允许缩放？

警告：其中一个表有一个存储文件的二进制列（每个记录最多5MB）

除此之外，我们还需要考虑Membership框架表，我们将扩展到另一个自定义表，并将用户逻辑映射到分区guid。

Answer 1

您希望您使用过不同的数据库：

• 如果您想要将数据库本身的权限授予客户端或超级用户。
• 如果您只想恢复一个客户端的数据库而不影响其他人的数据。
• 如果存在管理您的数据和数据泄露的监管问题，并且您姗姗来迟地发现这些法规只能通过拥有单独的数据库来满足。
• 如果您希望轻松将客户数据移动到多个数据库服务器或以其他方式扩展，或将更大/更重要的客户移动到不同的硬件。在世界的另一个角落。
• 如果您希望轻松归档和停用旧客户数据。
• 如果您的客户关心他们的数据被孤立，并且他们发现您没有这样做。
• 如果您的数据已被传唤，您必须生成整个数据库而不仅仅是一个客户的数据。
• 当你忘记保持警惕时，只有一个查询没有包含AND CustomerID = @CustomerID。提示：使用脚本化权限工具或模式，或使用包含WHERE CustomerID = SomeUserReturningFunction()或其中某些组合的视图包装所有表。
• 当您在应用程序级别获得权限错误并且客户数据暴露给错误的客户时。
• 当您希望为不同的客户端提供不同级别的备份和恢复保护时。
• 一旦你意识到构建一个基础设施来创建，配置，配置，部署和以其他方式启动/关闭新数据库是值得的投资，因为它会迫使你擅长它。
• 如果您没有考虑某类人员需要访问多个客户的可能性。数据，您需要在Customer之上设置一个抽象层，因为WHERE CustomerID = @CustomerID现在不会将其删除。
• 当黑客瞄准您的网站或系统时，您只需在一个数据库中获取管理员凭据后，就可以轻松获取所有数据。
• 当您的数据库备份需要5个小时才能运行然后失败时。
• 当您必须获得DBMS的企业版时，您可以进行压缩备份，以便通过网络复制备份文件只需不到5个小时更多。
• 当您必须每天将整个数据库还原到需要5个小时的测试服务器时，并运行需要2个小时才能完成的验证脚本。
• 当只有少数客户需要复制时，您必须将其应用于所有客户，而不仅仅是那些客户。
• 当您想要接触政府客户并发现他们需要您使用单独的服务器和数据库时，您的生态系统是围绕单个服务器和数据库构建的，而且它太难或者需要太久无法改变。

您会很高兴您使用了不同的数据库：

• 当一个客户的试点推出完全爆炸，而其他999个客户完全不受影响。您可以从备份恢复以解决问题。
• 当您的某个数据库备份失败并且您可以在25分钟内修复该数据库而不是再次启动整个10小时的过程。

您希望使用过单个数据库：

• 当您发现影响所有1000个客户端的错误并将修复程序部署到1000个数据库时很难。
• 当您在数据库级别获得权限错误并且客户数据暴露给错误的客户时。
• 如果您没有考虑某类人员需要访问所有数据库的子集（可能是两个客户合并）的可能性。
• 当你没有想到合并两个不同的数据库时会有多难。
• 当您合并了两个不同的数据库并意识到其中一个是错误的，并且您没有计划从这种情况中恢复。
• 当您尝试在单个服务器上增加超过32,767个客户/数据库时，发现这是SQL Server 2012中的最大值。
• 当你意识到管理1000多个数据库是一个比你想象的更大的噩梦。
• 当您意识到只是通过在表中添加一些数据就可以登上新客户时，您必须运行一堆可怕且复杂的脚本来创建，填充和设置新数据库的权限
• 当您每天必须运行1000个数据库备份时，请确保它们都成功，通过网络复制它们，将它们全部还原到测试数据库，并在每个备份上运行验证脚本，以某种方式报告任何故障将保证被看到，并且可以轻松快速地进行操作。然后其中150个在各个地方都失败了，必须一次修复一个。
• 当您发现必须为1000个数据库设置复制时。

仅仅因为我列出了更多的理由，并不意味着它更好。

有些读者可能会从这篇MSDN文章中获得价值：Multi-Tenant Data Architecture

Answer 2

如果您将您的架构称为“多租户”，Microsoft有一篇很好的文章值得一读here。它显示了"isolated" (multiple db)和"shared" (single db)之间的一些比较。通常，当租户（客户）的数量很大时共享获胜，但是当每个租户的规模很大时，建议采用孤立的方法。

然而，这些考虑只能由有经验的开发人员计算。

如果您设法使用isolated (multiple db)架构，仍然won't get direct benefit in performance when they are still run at same instance。如果您使用shared (single db)架构，请考虑使用int代替guid，或sequential guid，如果您仍需要使用它。