对多租户,或不对多租户

Question

我有一个困难的数据库设计决策,为我的客户基于网络的CRM的越来越多的分支机构提供多租户,我积极维护.

我很早就决定为每个分支使用单独的应用程序和单独的数据库,因为这是满足不同数据和代码要求的三个不同分支的最简单方法.我还想避免在每个查询中管理租户ID ,就像我在2007年建立的遗留经典ASP(cringe)应用程序一样......恐怖.

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

由于所有分支的表和视图都相同,并且现在可以使用更好的ORM工具来管理多租户应用程序,我想知道为多个分支创建共享数据库是否更好.

注意事项对于一个集中的数据库:

不太可能有多达10个分支机构.现在有3个.

在这方面具有实际经验的开发人员,您在我的情况下会做些什么？将应用程序和数据库分开,还是组合成一个巨大的系统？

编辑:伟大的微软的文章在多租户亲的利弊.我应该注意,分支之间的数据隔离不是主要问题.

Answer 1

如果你在谈论10个分支机构,多租户似乎是一个很大的成本,几乎没有什么好处.

您没有提及多租户的并发症:

版本控制变得困难.客户端X,Y和Z可能需要新功能,而客户端A,B和C则不需要.多租户应用程序使每个人都很难接受,特别是如果新功能需要更改数据库架构.这不是不可能的,只是更难.
有些客户对他们的数据在与其他客户端相同的表格中混杂感到非常不舒服.即使我们了解得更好,但对他们来说这也是一种安全风险.法律部门讨厌它.此外,如果您为客户端转储原始数据,则共享数据库需要谨慎.

您可以通过更好的实践消除一些痛点:

不要误会我的意思,我工作的一个更有趣的应用程序是多租户.可以带来巨大的好处,但是你可能会看到成千上万的客户,而不是十个.

Answer 2

咬紧牙关并合并它们.将租户ID添加到需要的位置,然后更改您的查询.

对于自定义,请查看允许您为特定客户端部署特定屏幕的插件类型体系结构.

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

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

我们一直在做多租户超过10年,而不是一次我回头看.一般来说,如果您在确认检索记录的人实际上是允许获取记录时已经具有安全意识,则查询并没有那么不同.

我不同意科尔宾提出的问题.应该已经通过具有基于属性的安全性结构来处理版本控制.这样您就可以通过用户或租户配置打开/关闭事物.此外,我发现很少有客户端A不希望客户端B要求的新功能.

关于数据混合的第二个问题也不是问题.只需查看salesforce.com或任何其他大型网站即可.他们绝对使用多租户架构,并根据使用它们的客户端的剪切数来判断,这似乎不是问题.这里的主要功能是能够确保您的客户的数据安全.