在针对多个客户端设计的以数据库为中心的应用程序中，我一直认为将单个数据库用于所有客户端将记录与正确的索引和键相关联是"更好"的选择。在听Stack Overflow播客时，我听到Joel提到FogBugz每个客户端使用一个数据库(因此，如果有1000个客户端，则将有1000个数据库)。使用这种架构的优势是什么？

我了解到，对于某些项目，客户需要直接访问此类应用程序中的所有数据，很明显每个客户都需要自己的数据库。但是，对于不需要客户端直接访问数据库的项目，每个客户端使用一个数据库有什么好处？从灵活性的角度来看，使用具有单个表副本的单个数据库要简单得多。添加新功能更容易，创建报表也更容易，管理也更容易。

我对"为所有客户提供一个数据库"方法非常有信心，直到听说Joel(经验丰富的开发人员)提到他的软件使用了不同的方法-我对他的决定有些困惑...

我听说人们援引数据库速度慢，但记录数量众多，但是任何具有某些优点的关系数据库都不会出现该问题，特别是如果使用了正确的索引和键。

任何输入，不胜感激！

解决方案

回答

好吧，如果一个客户告诉我们由于某些错误的导入作业或者类似原因而还原到其数据的较早版本怎么办？想象一下，如果我们告诉客户"由于所有客户之间都共享数据，我们将无法做到"或者"对不起，但是更改丢失了，因为客户X要求还原数据库"，客户会有什么样的感受。

回答

假设将所有客户端存储在一个数据库中不会带来扩展方面的损失；对于大多数人来说，配置良好的数据库/查询，如今确实如此。如果我们不是这些人中的一员，那么单个数据库的好处显而易见。

在这种情况下，受益于每个客户端的封装。从代码角度来看，每个客户端都是孤立存在的，因此不会存在数据库更新可能覆盖，破坏，检索或者更改属于另一个客户端的数据的情况。这也简化了模型，因为我们无需考虑记录可能属于另一个客户端这一事实。

我们还获得了可分离性的好处，将与给定客户端相关联的数据提取出来并将其移动到其他服务器很简单。或者使用内置的数据库机制在呼叫说"我们已经删除了一些关键数据！"时恢复该客户端的备份。

如果我们扩展一台数据库服务器的规模，我们将获得轻松，自由的服务器移动性，而我们只需在另一台服务器上托管新客户端即可。如果它们都在一个数据库中，则我们需要获得更强大的硬件，或者在多台计算机上运行数据库。

如果一个客户端希望使用软件版本1.0，而另一个客户端希望使用2.0和1.0，而2.0和1.0使用不同的数据库模式，则可以轻松地进行版本控制，而不必从一个数据库中拉出它们就可以进行迁移。

我想我还能想到几十个。但总的来说，关键概念是"简单性"。该产品管理一个客户，因此管理一个数据库。 "但是数据库还包含其他客户端"问题从没有任何复杂性。它适合用户的心理模型，他们单独存在。能够一次轻松地对所有客户进行报告的优势极少，我们需要多久一次就整个世界(而不仅仅是一个客户)进行报告？

回答

可扩展性。安全。我们公司的每个客户方法也使用1 DB。它还使代码也易于维护。

回答

感谢输入-所有出色和非常有效的观点。我想我正在寻找更多的升级灵活性。如果我们需要修改架构以添加新功能(对于Web应用程序来说)或者增强现有功能，则只需在单个数据库中完成操作即可。如果必须在1000个单独的数据库中复制此更改，则出错的机会会增加。如果操作失败怎么办？升级每个客户端需要多长时间？

如果保留正确的备份(或者如果数据库的结构从未真正覆盖过数据)，则为特定客户端还原数据将变得很简单。

代码的简单性虽然很重要，但实际上并没有变得非常复杂。根据所使用的语言和方法，创建仅代表特定客户端(存储特定客户端ID)的对象很简单，而项目的其余部分仅需为单个对象编码(类似于单个客户端) )。

可伸缩性是我们认为正确的事情，因为很容易将单个隔离的数据库移至其他物理服务器。但是，将服务器集群在一起甚至变得不集群也变得越来越容易，将每个客户端指向托管通用数据库的数据库SERVER似乎是一个很小的改变(因此，我们可以拥有两个或者三个仅托管数据库服务器)例如，每个数据库)。这种方法使升级过程仅限于三个数据库。

回答

"数据库"有两个含义

• 五金盒
• 正在运行的软件(例如" oracle")
• 特定的数据文件集
• 特定的登录名或者架构

Joel可能是较低层之一。在这种情况下，这仅是软件配置管理的问题……例如，我们不必修补1000个软件服务器即可修复安全漏洞。

我认为这是个好主意，因此，软件错误不会在客户端之间泄漏信息。想象一下带有错误的where子句的情况，该子句向我显示了客户数据以及我自己的客户数据。

回答

为了简单起见。我们可以确定客户只看到他们的数据。记录少的客户端不必为必须与数据库中可能存在的数十万条记录竞争而不必与之竞争的代价。我不在乎所有索引和优化的程度如何，会有查询确定它们必须扫描每条记录。

回答

这是我以前见过的一种方法：

• 每个客户都有一个唯一的连接字符串，存储在主客户数据库中。
• 数据库的设计使所有内容都可以按CustomerID进行细分，即使数据库上只有一个客户也是如此。
• 如果需要，将创建脚本以将所有客户数据迁移到新数据库，然后仅需要更新该客户的连接字符串以指向新位置。

这样一来，我们可以先使用一个数据库，然后在拥有大量客户之后便可以轻松地进行分段，或者当我们有几个客户过度使用系统时，更容易进行分段。

我发现，当所有数据都在同一数据库中时，还原特定客户数据确实很困难，但是管理升级要简单得多。

当每个客户使用一个数据库时，我们会遇到一个巨大的问题，那就是使所有客户都运行在相同的架构版本上，甚至不考虑在整个客户特定数据库上的备份作业。自然地恢复数据比较容易，但是如果我们确保不永久删除记录(只需用已删除的标记标记或者移至存档表)，那么首先就不需要数据库还原。

回答

至于一次升级1000台数据库服务器的痛苦，应该使用一些相当简单的自动化来解决。只要每个数据库都维护相同的架构，就不会真正成为问题。我们还使用每个客户方法使用数据库，因此对我们来说效果很好。

这是有关此确切主题的文章(是的，它是MSDN，但它是与技术无关的文章)：http://msdn.microsoft.com/zh-cn/library/aa479086.aspx。

关于与数据模型相关的多租户的另一讨论：http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

回答

在诸如医疗保健之类的受监管行业中，可能需要每个客户一个数据库，甚至可能需要一个单独的数据库服务器。

升级时更新多个数据库的简单答案是将升级作为事务进行，并在必要时进行快照，然后再进行升级。如果运行良好，则应该可以将升级应用于任何数量的数据库。

群集实际上并不是解决索引和全表扫描问题的解决方案。如果移至群集，则几乎不会有任何变化。如果我们有许多较小的数据库要分布在多台计算机上，则可以在没有群集的情况下更便宜地进行此操作。可靠性和可用性是考虑因素，但可以通过其他方式处理(某些人仍将需要集群，但大多数人可能不需要)。

我很想听听有关此情况的更多信息，因为集群不是一个简单的话题，并且在RDBMS世界中实现起来很昂贵。在非关系世界Google Bigtable等中，有很多关于集群的讨论/讨论。但是它们正在解决一系列不同的问题，并且失去了RDBMS的一些有用功能。

回答

我只是添加此答案以在此处包括多租户一词。我使用"多租户"作为查询进行搜索，但没有出现。