Database 架构：子客户（web）应用程序的一个或多个数据库

我已经构建了一个winforms应用程序，目前正在使用Web API等将其重建为ASP.NET MVC应用程序。稍后可能会添加一个应用程序

假设我将向少数客户提供这些应用程序。 我的申请是客户会计。 因此，我的所有客户都将使用我提供的应用程序管理他们的客户

这就引出了我的问题。我应该为所有客户使用一个大型数据库，还是为每个客户使用单独的数据库？我想对web应用程序实例、api等提出同样的要求

从技术上讲，我认为这两种选择都是可能的。如果这只是一种偏好，所有的输入都是值得赞赏的

我可以考虑一些利弊：

一个数据库：

• 易于设置/维护
• 为我的所有客户安装一个更新
• 无法为一个客户恢复数据库
• 资源分布不灵活
• 性能方面，这个数据库可能会变得非常大

多个数据库：

• 此外，数据库的规模较小，可以由多台服务器进行扩展
• 如果客户犯了“重大错误”，则易于恢复数据
• 提供客户特定需求的能力（atm不需要）
• 更难设置/维护，每个实例都需要单独更新
• 需要一种网关/路由工具将用户路由到正确的数据库/应用程序

---

我想知道“大公司”是如何做到这一点的。

您似乎在谈论数据库多租户，您对其利弊的看法是正确的

这个问题的答案在很大程度上取决于您正在构建的应用程序的类型以及它将拥有的客户的类型

如果需要，我会选择多租户（单DB多租户）数据库

您的应用程序是一个多租户应用程序

您的用户不需要存储自己的数据备份

对于每个客户，您的DB模式都不会更改（这在多租户应用程序中是隐含的）

您的租户/客户不会有大量的个人数据

您的客户没有需要遵守的政府强制数据隔离法律（欧盟数据在欧盟，美国数据在美国等）

对于单个数据库来说，几乎是所有这些点的倒数