在为多个客户端设计的以数据库为中心的应用程序中，我一直认为对所有客户端使用单个数据库“更好”——将记录与正确的索引和键相关联。在收听 Stack Overflow 播客时，我听到 Joel 提到 FogBugz 每个客户端使用一个数据库（因此，如果有 1000 个客户端，就会有 1000 个数据库）。使用这种架构有什么优点？
据我了解，对于某些项目，客户需要直接访问其所有数据 - 在这样的应用程序中，显然每个客户都需要自己的数据库。但是，对于客户端不需要直接访问数据库的项目，每个客户端使用一个数据库有什么优势吗？就灵活性而言，使用单个数据库和单个表副本似乎要简单得多。添加新功能更容易，创建报告更容易，而且管理也更容易。
我对“所有客户的一个数据库”方法非常有信心，直到我听到 Joel（一位经验丰富的开发人员）提到他的软件使用了不同的方法 - 我对他的决定有点困惑......
我听说人们引用大量记录时数据库会变慢，但是任何具有一定优点的关系数据库都不会出现这个问题 - 特别是如果使用正确的索引和键。
任何意见都将不胜感激！
假设将所有客户端存储在一个数据库中不会造成扩展损失；对于大多数人来说，以及配置良好的数据库/查询，现在这将是相当正确的。如果您不是这些人中的一员，那么单一数据库的好处是显而易见的。
在这种情况下，好处来自于每个客户端的封装。从代码的角度来看，每个客户端都是孤立存在的 - 数据库更新不可能覆盖、损坏、检索或更改属于另一个客户端的数据。这也简化了模型，因为您无需考虑记录可能属于另一个客户端的事实。
您还可以获得可分离性的好处 - 提取与给定客户端关联的数据并将它们移动到不同的服务器非常简单。或者，当调用“我们已经删除了一些关键数据！”时，使用内置数据库机制恢复该客户端的备份。
您可以获得轻松且免费的服务器移动性 - 如果您扩展一台数据库服务器，您可以在另一台服务器上托管新客户端。如果它们全部位于一个数据库中，则您需要获得更强大的硬件，或者在多台计算机上运行数据库。
您可以轻松进行版本控制 - 如果一个客户端想要保留软件版本 1.0，而另一个客户端想要 2.0，其中 1.0 和 2.0 使用不同的数据库模式，那么没有问题 - 您可以迁移一个客户端，而无需将它们从一个数据库中取出。
我想我还能想到几十个。但总而言之，关键概念是“简单”。该产品管理一个客户端，从而管理一个数据库。 “但是数据库还包含其他客户端”问题从来没有任何复杂性。它符合用户单独存在的心理模型。能够同时对所有客户进行简单报告之类的优势是微不足道的 - 您多久需要一份关于整个世界而不仅仅是一个客户的报告？
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
