我应该使用单个或多个数据库设置一个多用户应用程序？

Question

我的工作PHP应用程序，打算减轻公司的工作流程和项目管理，我们说喜欢的东西 大本营 和 GoPlan.

我不知道什么最好的办法是，数据库的明智的。我应该用一个单一的数据库和增加客户的特定列的每个桌子，或者我应该创建一个数据库对每个新客户？一个重要因素是自动化：我希望它是死的简单的创建一个新的客户(也许是开放的可能性，签署了你自己)。

可能的缺点我可以认为使用一个数据库：

• 缺乏扩展性
• 安全问题(虽然错误 不应该放在第一位)

你有什么想法吗？你有任何想法什么解决办法，上述公司是最有可能选择了?

Answer 1

我通常会增加ClientID的所有表格，并与一个数据库。但由于数据库通常是难以扩展，我还将使它能够运行在不同数据库实例中的一些或所有客户。

这样你可以有一堆小客户在一个数据库，大部分在单独的服务器。

一个关键因素虽然可维护性，保持架构相同的所有数据库。会有头痛足以管理的版本控制不引入客户的具体模式。

Answer 2

听计算器的播客，其中乔和杰夫谈论同样的问题。乔尔是在谈论自己的经验提供一个托管版本的软件。他指出，增加客户标识所有数据库复杂的设计和编码(你确定你没有不小心忘了给它添加到那里的一些条款？) 和复杂的托管功能，例如特定客户的备份。

这是在集第20或第21(检查成绩单细节)。

Answer 3

在我看来，这将取决于您可能的客户基础。如果你可以得到进入的情况下拱手都是使用你的系统，然后你会变得更好，有独立的数据库。它还取决于如何将多个数据库得到实施，通过你的DBMS。如果每个数据库有一个独立的副本的基础设施，然后表明一个单一的数据库(或改变DBMS)。如果多个数据库，可以供应通过一个单一的副本的基础设施，然后我去单独的数据库。

认为数据库备份。客户说"请给我一份我的数据"。很多，很容易在一个单独的数据库安装于如果一个单一的数据库是共用的。认为删除一个客户；再次，容易得多单独的数据库。

(该"基础设施"的一部分是米勒口，因为存在着很大的差异之间的不同DBMS关于什么构成了一个数据库'和'服务器的实例，例如。 添加:问题是标签'mysql'，所以或许这些想法并不完全相关。)

添加:一个问题-有多个客户在一个单一的数据库，每个SQL query是需要确保数据的正确客户选择。这意味着SQL将是难以编写和阅读，并DBMS会必须更加努力地工作，在处理数据和指数将会更大，而且...我真的会去一个单独的数据库每个客户为许多目的。

显然，计算器(作为一个例子)不具有独立的数据库每户；我们都使用相同的数据库。但如果你们的会计系统，为不同的公司，我不认为这是可以接受的(公司，可能是不法的人)，以分享的数据库。

Answer 4

• 发展 对于迅速发展，使用一个数据库，每位客户。认为如何容易将是备份，恢复，或者删除一个客户的数据。或措施/监测/法案的使用情况。你不需要编写代码自己做的，只是利用你的数据库元。

• 性能 对于业绩，使用一个数据库。认为关于连接的集、共享存储器，高速缓存，等等。

• 业务 如果你的业务计划是有许多小型的客户(认为hotmail)你应该很可能工作一个单一的数据库。和所有管理任务的这种注册，删除，数据迁移，等等。完全自动化，并暴露在一个友好的接口。如果你的计划有几十个或几百个大客户然后你可以在一个数据库每个客户和具有系统管理脚本到位，可以通过你的客户支持工作人员。

Answer 5

下 视频 解释了它是如何做上salesforce.com.他们使用一个数据库有一种特殊列OrgId其识别每个租户的数据。还有更多，所以你应该看看这个。我要去与他们的方法。

还有另外一个伟大的 文章 关于在MSDN。它说明了在深度时应使用一个共用或分离的做法。记住，具有一个共用数据库所有住户中有一些重要的安全问题和如果所有的都分享相同的数据库对象的你可能需要使用[排一级安全]-根据DBMS使用(我敢肯定这有可能在MS SQL服务器和Oracle，可能是在IBM DB2也同样)。你可以使用的技巧喜欢 行级安全mySQL 要实现类似的结果(见+触发器).

Answer 6

对于多组织、业绩通常会增加更多的资源管理，以分享跨越租户，看到

http://en.wikipedia.org/wiki/Multitenancy

因此，如果可以的话，去与个单一的数据库。我同意，安全问题只会发生由于错误的，因为你可以实现所有访问控制在应用程序。在一些数据库的数据，仍然可以使用该数据库的访问控制，通过谨慎使用的观点(因此，每个经认证的用户得到一个不同的图)。

有方法可以提供扩展。例如，您可以创建一个单一的表与延伸的属性(键的租客，库记录，以及延伸的属性id)。或者你可以创建每承租人延表，使得每个承租人都有他自己的扩展架构。

Answer 7

当你设计一个多租户数据库，通常有三种选择：

1. 有一个数据库每个租户
2. 有一个方案每个租户
3. 所有住户分享同一表格(s)

选择你选择有影响的可扩展性，可扩展性和隔离。这些影响已广泛讨论了在不同的 计算器的问题 和数据库的文章。

在实践中，每三个设计方案-有了足够的努力可以解决问题的规模，数据变化在住户和隔离。决定取决于主要维你在建筑物。该摘要:

• 如果你建设的规模：所有住户分享同一表格(s)
• 如果你是在建设隔离：创建一个数据库每个租户

例如， 谷歌 人和潜在客户添加按照第一种模式，并有自己的住户分享同一表格。计算器上的其他手下的第二种模式，并保持一个数据库每承租人。第二种也是更普遍的在受监管的行业，例如医疗保健。

决定下来到主要维你在优化数据库的设计。 这篇文章在设计你SaaS数据库的规模 谈到权衡和提供的摘要在下文PostgreSQL。

Answer 8

要考虑的另一点是，可能有法律义务保持一个公司的数据独立的信息'.

Answer 9

有一个数据库每个客户通常不会规模。MySQL(以及可能的其他数据库)拥有的资源打开每个表，这并不适用于10+表上的一个实例，这将发生在一个大规模多租户的情况。

当然，如果你有一些其他问题，这会导致其他问题之前，你得到这个水平，这可能不是相关的。

此外，"碎片"多租户应用程序是有可能欧元是正确的事情做到最终作为你的应用程序得到越来越大。

分区并不意味着一个数据库(或)每个租户，但每一个碎片或碎片，这可能有几个住户的每一个。你会需要找到正确调整参数为自己，也许在生产(因此它可能需要相当可调从一开始)

€我不能保证这一点。

Answer 10

你可以开始一个单一的数据库和分区这一作用的增长。如果你这样做，有几件事情我会的建议：

1)设计数据库的一种方式，它可以容易地进行分配。例如，如果客户是要分享数据、确保数据是很容易地复制到每个数据库。

2)当你只有一个数据库，确保它是被支持的另一个物理的服务器。在发生转移，你可以恢复交通要这种其他服务器，仍然有数据完好无损。