在为多个客户端设计的以数据库为中心的应用程序中,我一直认为为所有客户端使用单个数据库"更好" - 将记录与适当的索引和密钥相关联.在收听Stack Overflow播客时,我听到Joel提到FogBugz每个客户端使用一个数据库(所以如果有1000个客户端,则会有1000个数据库).使用这种架构有什么好处?
据我所知,对于某些项目,客户需要直接访问所有数据 - 在这样的应用程序中,很明显每个客户端都需要自己的数据库.但是,对于客户端不需要直接访问数据库的项目,每个客户端使用一个数据库有什么好处吗?似乎在灵活性方面,使用具有表的单个副本的单个数据库要简单得多.添加新功能更容易,创建报告更容易,而且管理起来更容易.
我对"所有客户的一个数据库"方法非常有信心,直到我听到Joel(一位经验丰富的开发人员)提到他的软件采用了不同的方法 - 我对他的决定感到有些困惑......
我听说人们引用数据库会因为大量记录而变慢,但任何具有一些优点的关系数据库都不会出现这个问题 - 特别是如果使用了正确的索引和键.
任何输入都非常感谢!
假设将所有客户端存储在一个数据库中没有缩放惩罚; 对于大多数人来说,以及配置良好的数据库/查询,这些日子都是相当正确的.如果你不是这些人中的一个,那么单个数据库的好处是显而易见的.
在这种情况下,好处来自每个客户端的封装.从代码的角度来看,每个客户端都是孤立存在的 - 没有可能的情况,数据库更新可能会覆盖,损坏,检索或更改属于另一个客户端的数据.这也简化了模型,因为您不需要考虑记录可能属于另一个客户端的事实.
您还可以获得可分离性的好处 - 从提取与给定客户端关联的数据并将它们移动到不同的服务器是微不足道的.或者在使用内置数据库机制调用"我们删除了一些关键数据!"时恢复该客户端的备份.
您可以获得简单且免费的服务器移动性 - 如果您超出一个数据库服务器,则可以在另一台服务器上托管新客户端.如果它们都在一个数据库中,那么您需要获得更强大的硬件,或者在多台计算机上运行数据库.
您可以轻松进行版本控制 - 如果一个客户端希望保留软件版本1.0,而另一个客户端想要2.0,其中1.0和2.0使用不同的数据库模式,则没有问题 - 您可以迁移一个而无需将它们从一个数据库中删除.
我想,我可以想到几十个.但总而言之,关键概念是"简单".该产品管理一个客户端,因此管理一个数据库."数据库还包含其他客户端"问题从未出现任何复杂性.它适合用户的心理模型,它们独自存在.能够一次轻松地对所有客户进行简单报告的优势很少 - 您想要在全世界报告的频率,而不仅仅是一个客户端?
这是我以前见过的一种方法:
每个客户都有一个存储在主客户数据库中的唯一连接字符串.
数据库的设计使得一切都按CustomerID进行细分,即使数据库上只有一个客户也是如此.
创建脚本以在需要时将所有客户数据迁移到新数据库,然后只需要更新该客户的连接字符串以指向新位置.
这允许首先使用单个数据库,然后在您拥有大量客户端后轻松分段,或者更常见的是当您有几个客户过度使用系统时.
我发现当所有数据都在同一个数据库中时,恢复特定的客户数据非常困难,但管理升级要简单得多.
当每个客户使用一个数据库时,会遇到一个巨大的问题,即让所有客户在相同的模式版本上运行,甚至不考虑在一大堆客户特定数据库上的备份作业.自然地恢复数据更容易,但如果您确保不永久删除记录(只需标记已删除的标记或移动到存档表),那么您首先需要更少的数据库恢复.
保持简单.您可以确定您的客户只看到他们的数据.记录较少的客户不必支付与数据库中可能存在的数十万条记录竞争的惩罚,而不是他们的记录.我不关心所有内容的索引和优化程度,会有查询确定他们必须扫描每条记录.
那么,如果您的一个客户告诉您由于某些拙劣的导入工作或类似问题而恢复到其早期版本的数据会怎么样?想象一下,如果您告诉他们"您不能这样做,因为您的数据在我们所有客户之间共享"或"抱歉,但由于客户X要求恢复数据库而导致您的更改丢失",您的客户会有何感受.
至于一次升级1000个数据库服务器的痛苦,一些相当简单的自动化应该照顾它.只要每个数据库都维护相同的模式,那么它就不会成为问题.我们还使用每个客户端的数据库方法,它适用于我们.
这是一篇关于这个确切主题的文章(是的,它是MSDN,但它是一篇独立于技术的文章):http://msdn.microsoft.com/en-us/library/aa479086.aspx.
关于多租户的另一个讨论,因为它与您的数据模型有关:http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx
可扩展性.安全.我们公司每个客户的方法也使用1个DB.它还使代码更容易维护.