在StackOverflow 播客中没有。在19 日，Joe 描述了 Fogcreek 的决定，即每个客户端都拥有一个数据库，而不是所有客户端都拥有一个数据库。这让我想到了以下几点。
所以这意味着我将有1000 x 100 x 1000 = 100,000,000 个产品与用户相关联。现在，如果我对一个用户及其所有客户的产品进行连接表查询，那么如果我为此目的只使用一个数据库，那么合理的查询时间应该是多少？
更新
也许我的问题不够清楚。假设我需要对上面描述的数据集进行各种时髦的查询（最小、最大、组等），是否会很慢（或没有）到拥有多个数据库策略更有意义的地步，例如. 1 DB/客户端、数据库分片等
我想答案取决于您选择的 DBMS。以 Oracle 为例，1 个大数据库肯定更可取，实际上 1000 个相同的数据库会被认为是荒谬且难以管理的。
此外，您永远不需要跨用户运行查询吗？例如，找到拥有最多产品的用户。或者这些真的是 1000 个离散的“私有”数据库，没有人可以全面访问数据？即便如此，Oracle 例如提供“虚拟专用数据库”来满足单个数据库中的需求。
每个客户端一个数据库策略的主要原因是安全性和可管理性。虽然在单个数据库而不是 100 个特定于客户端的数据库上进行备份/恢复的概念确实让您获胜，但它也有一些缺点。共享数据库的一些问题是：
如果没有一些额外的安全措施（例如视图），用户不能直接从数据库报告，以防止他们看到彼此的数据。在敏感数据的情况下，这也成为合规问题。
整个应用程序必须了解安全模型，这增加了一定程度的复杂性。同样，对于敏感数据，这具有合规性影响。
涉及一位客户数据的系统维护或支持工单任务存在错误会影响其他客户数据的风险。
多个数据库的固有分区简化了应用程序并消除了整个类别的错误、错误配置和安全问题。如果您构建应用程序，使其能够进行自动化配置管理和部署到多个环境，那么即使在多个实例上，您也可以获得相当容易维护的东西。
此外，根据您所描述的数据量和报告类型，您最好构建某种报告子系统或数据集市，将报告移出生产服务器。这种类型的分析报告在星型模式上比在事务数据库上使用的规范化模式类型更有效。
在大多数情况下，您应该将用户和/或客户端作为 PK 的一部分，因此您在多租户场景中的性能不会受到与单租户情况有太大不同的影响。
如果你想得到所有这些，所有的列和行，而不过滤或聚合，那么你将不得不等待很长时间。我认为这里没有任何合理的时间可以用作基准。你只需要等待:)
但是这些类型的查询很少发生（除非您正在迁移数据 - 仍然有替代方案）。通常发生的情况是您返回子集行、行页、列选择或聚合。在这种情况下，“合理的数量”取决于查询的类型和所涉及的计算。