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

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




我正在考虑一个数据库设计问题。任何帮助将不胜感激。

我们正在设计一个有 20 个表的应用程序(在新功能开发过程中可能会增加到大约 30 个)

技术栈

MVC4、.NET 4.X、Entity Framework 5、SQL Server 2012、ASP.NET 成员资格框架

用户数量

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

问题

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

或者

寻找多个数据库，这在新功能发布和错误修复期间可能会很困难。但是可能允许扩展？

注意事项:其中一个表有一个存储文件的二进制列(每条记录最大 5MB)

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

Answer 1

你会希望你使用了单独的数据库:

如果您想将数据库本身的权限授予客户端或 super 用户。

如果您只想恢复一个客户端的数据库而不影响其他客户端的数据。

如果您的数据和数据泄露存在监管问题，并且您后来发现只有拥有单独的数据库才能满足这些规定。

如果您想轻松地将客户数据移动到多个数据库服务器或以其他方式横向扩展，或者将更大/更重要的客户移动到不同的硬件。在世界的不同地方。

如果您想轻松存档和停用旧客户数据。

如果您的客户关心他们的数据被孤立，而他们发现您没有这样做。

如果您的数据被传唤并且很难仅提取一位客户的数据，或者传票过于宽泛，您必须生成整个数据库，而不仅仅是为一位客户生成数据。

当您忘记保持警惕并且只有一个不包含 AND CustomerID = @CustomerID 的查询漏掉时.提示:使用脚本化的权限工具或模式，或使用包含 WHERE CustomerID = SomeUserReturningFunction() 的 View 包装所有表。 ，或这些的某种组合。

当您在应用程序级别获得权限错误并且客户数据暴露给错误的客户时。

当您希望为不同的客户端提供不同级别的备份和恢复保护时。

一旦您意识到构建基础设施来创建、供应、配置、部署和以其他方式启动/关闭新数据库是值得的投资，因为它迫使您精通它。

当您不允许某类人需要访问多个客户的数据，并且您需要在 Customer 之上的抽象层时因为 WHERE CustomerID = @CustomerID现在不会剪了。

当黑客以您的网站或系统为目标时，您让他们在仅在一个数据库中获得管理员凭据后，就可以轻松地一举获取所有客户的所有数据。

当您的数据库备份运行需要 5 个小时然后失败时。

当您必须获得 DBMS 的企业版时，您才能进行压缩备份，这样通过网络复制备份文件所需的时间还不到 5 小时。

当您必须每天将整个数据库还原到需要 5 小时的测试服务器，并运行需要 2 小时才能完成的验证脚本时。

当只有少数客户需要复制时，您必须将其应用于所有客户，而不仅仅是少数客户。

当您想接手政府客户并发现他们要求您使用单独的服务器和数据库时，但您的生态系统是围绕单个服务器和数据库构建的，这太难了，或者需要很长时间才能改变。

你会很高兴你使用了单独的数据库:

当对一个客户的试点部署完全爆炸而其他 999 个客户完全不受影响时。您可以从备份中恢复以解决问题。

当您的一个数据库备份失败时，您可以在 25 分钟内修复那个，而不是重新开始整个 10 小时的过程。

您会希望您使用的是单个数据库:

当您发现影响所有 1000 个客户端的错误并且将修复程序部署到 1000 个数据库是困难的。

当您在数据库级别获得权限错误并且客户数据暴露给错误的客户时。

当您不允许某些类别的人需要访问所有数据库的子集时(可能是两个客户合并)。

当您没有想到合并两个不同的数据数据库会有多困难时。

当您合并了两个不同的数据数据库并意识到一个是错误的，并且您没有计划从这种情况中恢复时。

当您尝试在单个服务器上增长超过 32,767 个客户/数据库并发现这是 SQL Server 2012 中的最大值时。

当您意识到管理 1,000 多个数据库是一场比您想象的更大的噩梦时。

当您意识到无法仅通过在表中添加一些数据来加入新客户时，您必须运行一堆可怕而复杂的脚本来创建、填充和设置新数据库的权限。

当您每天必须运行 1000 个数据库备份时，请确保它们全部成功，通过网络复制它们，将它们全部还原到测试数据库，并在每个数据库上运行验证脚本，并以一种保证失败的方式报告任何失败被看到，并且可以轻松快速地采取行动。然后其中 150 个在不同的地方失败，必须一次修复一个。

当您发现必须为 1000 个数据库设置复制时。

仅仅因为我列出了更多的原因并不意味着它更好。
有些读者可能会从 MSDN: Multi-Tenant Data Architecture 获得值(value).或者也许 SaaS Tenancy App Design Patterns .甚至 Developing Multi-tenant Applications for the Cloud, 3rd Edition