要多租户，还是不要多租户 [英] To Multi-Tenant, or Not To Multi-tenant
问题描述
我有困难的数据库设计的决定，使有关多租户为越来越多的我的客户的基于Web的CRM，我积极维护的分支。
I have a difficult database design decision to make regarding multi-tenancy for the growing number of branches of my client's web-based CRM, which I actively maintain.
我决定早早就使用与每个分支独立的数据库独立的应用程序，因为这是照顾有不同的数据和code要求三个不同的分支最简单的方法。我也想避免在管理租户的ID的每个的查询，像我不得不与传统经典ASP（畏缩的）应用程序，我建于2007年......恐怖。
I made the decision early on to use separate applications with separate databases for each branch, because it was the simplest way to cater for three different branches with disparate data and code requirements. I also wanted to avoid managing Tenant IDs in every query, like I had to with the legacy Classic ASP (cringe) application I built in 2007...the horror.
但是，现在的分支机构的数据要求正在融合，并随着业务的扩大，我需要能够快速推出新的分支机构，全球共享产品SKU。
But now the data requirements for branches are converging and as the business expands, I need to be able to roll out new branches quickly and share global product SKUs.
由于表和视图都是相同的所有分支和更好的ORM工具现可管理多租户应用程序，我不知道这将是更好的有多个分支共享数据库。
Since tables and views are the same for all branches and better ORM tools are now available to manage multi-tenant applications, I wonder if it would be better to have a shared database for multiple branches.
- 全球产品SKU
- 简化库存申请
- 更容易备份
- 部署一次，而不是对每一个分支
- 更容易区分有独立的数据块的分支要求
- 模块化部署（一个被击倒的分支机构不打破所有）
- 更难管理和开发共享DB
- 我要重新设计的发票编号（由种子生成的序列）
- 少WHERE子句到处
- 恢复一个受损的分支有很多的其他分支影响
这是不可能会有永远是多达10个分支机构。现在有3个。
It is unlikely there will be ever be as many as 10 branches. Right now there are 3.
在这一领域的实际经验的开发人员，你会在我的情况怎么办？保持应用和放大器;数据块分开，或者合并为一个巨制？
Developers with real-world experience in this area, what would you do in my situation? Keep apps & DBs separate, or combine into one giant system?
编辑：
Great Microsoft article on multi-tenancy pro's and cons. I should note that data isolation between branches is not a major issue.
推荐答案
硬着头皮合并。添加您的租户ID其中，它需要和改变你的查询。
Bite the bullet and merge them. Add your tenant ID where it needs to be, and change your queries.
有关定制，寻找到一个插件式架构，允许您为特定的客户部署特定的屏幕。
For customizations, look into a plugin type architecture that would allow you to deploy specific screens for particular clients.
我们有一个建在这样一个时尚的软件产品。有时它是部署在客户现场，有时我们对其进行托管。对于所有意图和目的是的幅度更容易处理一个code有客户特定的扩展比对付code的多个分支基地的命令。
We have a software product that is built in just such a fashion. Sometimes it's deployed on a client site, sometimes we host it. For all intents and purposes it is an order of magnitude easier to deal with a single code base that has client specific extensions than dealing with multiple branches of the code.
首先，当我们解决问题，我们解决它的每一个人。当然，如果我们打破它，我们打破它适合所有人，但，这就是单元测试是。它是一个很大的赫克更容易维护一组对一code基本单元测试比它是保持他们多个分支。
For one, when we fix a problem, we fix it for everyone. Sure, if we break it, we break it for everyone but that's what unit tests are for. And it is a heck of a lot easier to maintain a set of unit tests against one code base than it is to maintain them for multiple branches.
我们一直在做的多租户超过10年，没有一次有我回头一看。一般来说，查询是没有什么不同，如果你已经安全意识在验证检索记录的人实际上是允许得到它。
We've been doing multi-tenant for over 10 years and not once have I looked back. Generally speaking, queries aren't that different if you are already security conscious in verifying that the person retrieving the record is actually allowed to get it.
我不同意由科尔宾提出的问题。周围的版本应该已经到位有一个基于属性的安全结构来处理。这样，你可以通过用户或租户配置开启/关闭的事情。另外，我觉得很罕见的，客户端A不希望同样的新功能，客户B要求。
I disagree with the issues brought up by Corbin. The one around versioning should already be handled by having an attribute based security structure in place. That way you can turn things on/off via user or tenant configuration. Also, I find it very rare that client A doesn't want the same new feature that client B asked for.
有关数据交融第二个也是一个非问题。只要看看salesforce.com或任何其他大型网站。他们绝对使用多租户架构和使用它们的客户的剪切次数判断这似乎并不成为一个问题。这里最主要的是能够确保你的客户，他们的数据是安全的。
The second one about data mingling is also a non-issue. Just look at salesforce.com or any of the other large scale sites. They absolutely use a multi-tenant architecture and judging by the shear number of clients that use them this doesn't seem to be a problem. The main thing here is being able to ensure to your clients that their data is secured.
这篇关于要多租户，还是不要多租户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
