架构:子客户的一个或多个数据库(网络)APP

时间:2017-06-07 19:13:12

标签: database web-services architecture

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

假设我将这些应用程序提供给少数客户。 我的应用程序用于客户会计。 所以我的所有客户都会在我提供的应用程序中管理他们的客户。

这让我想到了我的问题。我应该为我的客户使用一个大数据库,还是应该为每个客户使用单独的数据库?我想问一下网络应用实例,api等等。

技术上我认为两种选择都是可能的。如果它只是一个偏好的选择,那么所有的输入都会受到赞赏。

我能想到的一些优点和缺点:

一个数据库:

  • 易于设置/维护
  • 为我的所有客户安装一个更新
  • 无法为一个客户恢复数据库
  • 在资源传播方面不灵活
  • 性能,这个db可以得到真正的大

多个数据库:

  • 性能,数据库规模较小,可由多台服务器传播
  • 如果客户犯了一个巨大的错误,
  • 轻松恢复数据
  • 提供客户特定需求的能力(不需要atm)
  • 难以设置/维护,每个实例都需要单独更新。
  • 需要一种网关/路由功能来将用户路由到正确的数据库/应用程序

我想知道'大公司'接近这个。

1 个答案:

答案 0 :(得分:2)

您似乎在谈论数据库多租户,而您的利弊是正确的。

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

如果

,我会使用多租户(单个DB多租户)数据库
  1. 您的应用程序是一个多租户应用程序。
  2. 您的用户无需存储自己的数据备份。
  3. 您的数据库架构不会因每个客户而改变(无论如何,这隐含在多租户应用程序中)。
  4. 您的租户/客户不会拥有大量的个人数据。
  5. 您的客户没有政府强制要求他们遵守的数据隔离法律(欧盟的欧盟数据,美国的美国数据等)。
  6. 对于个人数据库而言,几乎与所有这些点相反。