我早点作出决定，为每个分支使用单独的数据库单独的应用程序，因为它是以不同的数据和代码要求来满足三个不同的分支的最简单的方法。我也想避免在每个查询中管理租户ID，就像我不得不使用我在2007年建立的旧版ASP(cringe)应用程序…恐怖。
但现在分支机构的数据要求正在趋同，随着业务的扩大，我需要能够快速推出新的分支机构，并共享全球产品SKU。
由于表和视图对于所有分支是相同的，更好的ORM工具现在可用于管理多租户应用程序，我不知道为多个分支拥有一个共享数据库是否会更好。
集中式数据库的注意事项：
>全球产品SKU
>简化库存请购单
更容易备份
>部署一次而不是每个分支
对集中式数据库的注意事项：
更容易地使用单独的DB来区分分支需求
>模块化部署(一个分支不破坏所有)
>更难管理和开发共享DB
>我必须重新设计发票编号(由种子生成的序列)
> where WHERE子句无处不在
恢复一个分支对其他分支有很大的影响
不可能有多达10个分支机构。现在有3个。
在这方面具有现实世界经验的开发商，在我的情况下你会做什么？保持应用和DB分开或组合成一个巨型系统？
编辑：伟大的Microsoft article多租户专业和缺点。我应该注意，分支机构之间的数据隔离不是一个主要问题。
解决方法
对于自定义，请查看一种插件类型架构，这样可以为特定客户端部署特定的屏幕。
我们有一个以这种方式建立的软件产品。有时它被部署在客户端站点上，有时候我们托管它。对于所有意图和目的，处理具有客户端特定扩展的单个代码库比处理代码的多个分支更容易处理一个数量级。
一方面，当我们解决问题时，我们会为每个人解决问题。当然，如果我们打破它，我们会为大家打破它，但这是单元测试。对于一个代码库，维护多个分支的单元测试是一个很容易的事情。
我们一直在做多租户十多年，而不是一次回头。一般来说，如果您已经有安全意识来验证检索记录的人实际上是允许的话，那么查询并没有那么大。
我不同意科尔宾提出的问题。应该已经通过使用基于属性的安全结构来处理版本控制。这样，您可以通过用户或租户配置打开/关闭东西。此外，我发现客户端A不希望客户端B要求的相同的新功能非常罕见。
关于数据混合的第二个也是一个非问题。只需查看salesforce.com或任何其他大型网站。他们绝对使用多租户架构，并根据使用它们的客户端的剪切数量来判断这似乎不是问题。这里的主要目的是能够确保您的客户他们的数据是安全的。
