asp.net - Multi-Tenancy 或非 Multi-Tenancy

Question

对于我积极维护的客户基于 Web 的 CRM 的分支机构数量不断增加的 Multi-Tenancy ，我需要做出一个艰难的数据库设计决策。

我很早就决定为每个分支使用具有单独数据库的单独应用程序，因为这是满足具有不同数据和代码要求的三个不同分支的最简单方法。我还希望避免在每个查询中管理租户 ID，就像我在 2007 年构建的传统经典 ASP(畏缩)应用程序中所做的那样……太恐怖了。

但现在分支机构的数据需求正在趋同，随着业务的扩展，我需要能够快速推出新分支机构并共享全局产品 SKU。

由于所有分支的表和 View 都是相同的，并且现在可以使用更好的 ORM 工具来管理 Multi-Tenancy 应用程序，因此我想知道为多个分支使用共享数据库是否会更好。

集中式数据库的注意事项:

• 全局产品 SKU
• 简化库存申请
• 更容易备份
• 部署一次而不是每个分支部署

针对集中式数据库的考虑因素:

• 通过单独的数据库更容易区分分支需求
• 模块化部署(一个分支崩溃并不会破坏所有分支)
• 共享数据库更难管理和开发
• 我必须重新设计发票编号(由种子生成的序列)
• 到处都减少 WHERE 子句
• 恢复一个损坏的分支对其他分支有很多影响

不太可能有多达 10 个分支机构。目前有 3 个。

在该领域拥有实际经验的开发人员，如果遇到我的情况，你们会怎么做？将应用程序和数据库分开，还是合并成一个巨大的系统？

<小时/>

编辑: 太棒了 Microsoft article关于 Multi-Tenancy 的利弊。我应该指出，分支之间的数据隔离不是主要问题。

Answer 1

硬着头皮将它们合并。在需要的位置添加您的租户 ID，然后更改您的查询。

对于自定义，请研究插件类型架构，该架构允许您为特定客户端部署特定屏幕。

我们有一个软件产品就是以这种方式构建的。有时它部署在客户端站点上，有时我们托管它。出于所有意图和目的，处理具有客户端特定扩展的单个代码库比处理代码的多个分支更容易处理一个数量级。

首先，当我们解决问题时，我们会为每个人解决问题。当然，如果我们破坏了它，我们就会为每个人破坏它，但这就是单元测试的目的。针对一个代码库维护一组单元测试比为多个分支维护它们要容易得多。

我们从事 Multi-Tenancy 业务已经有 10 多年了，我一次也没有回头。一般来说，如果您在验证检索记录的人实际上是否有权获取该记录时已经具有安全意识，那么查询并没有那么不同。

我不同意Corbin提出的问题。围绕版本控制的问题应该已经通过建立基于属性的安全结构来处理。这样您就可以通过用户或租户配置来打开/关闭功能。另外，我发现客户 A 不想要客户 B 所要求的相同新功能的情况很少见。

关于数据混合的第二个也不是问题。只需查看 salesforce.com 或任何其他大型网站即可。他们绝对使用 Multi-Tenancy 架构，并且从使用它们的客户端数量来看，这似乎不是问题。这里最主要的是能够确保您的客户的数据是安全的。