数据库架构问题：每个客户 1 个表或所有客户的 1 个唯一表

Question

我们需要知道哪种数据库架构更适合使用以及为什么。

我们有一个客户列表，他们都将使用相同的表结构（很少有例外）。

我们将有大约 10,000 个客户，每个客户可能都有大约 50,000 种产品。

每个客户对产品的处理可能不同，我们还希望提供一个计划，让客户可以通过 API 访问他们的数据。

我们的客户确实销售产品，他们的 SQL 表结构都会有如下列：

• Feed_ID
• 产品编号
• 产品描述
• 价钱
• 重量
• 等等...

这 Feed_ID用于区分这些产品的原产地，将是为每个客户独特的-当然。

我们思考过的关系表结构的3种选择：

1. 每个客户都有自己的数据库，在该数据库中，每个产品提要有 1 个表

2. 所有客户都托管在 1 个唯一的数据库下，在该数据库下，所有客户每个提要都有 1 个表 - 在这种情况下，如果他作为 2 个不同的产品提要，则 1 个客户可以有 2 个表。

3. 所有客户都托管在 1 个独特的数据库下，但是，在第三个解决方案中，我们只有 1 个独特的表来托管所有客户的所有产品提要。

您会使用哪种解决方案，为什么您认为您选择的解决方案更好？

谢谢你。

Answer 1

你还没有提供足够的信息。在几乎所有情况下（例外情况见下文），您都需要为所有客户设置一组表。以下是一些原因：

• 表现。表格的激增意味着数据分布在更多的数据页中，因此您有很多部分填充的数据页。数据库更大，处理速度更慢。
• 编码效率。如果客户的表都具有不同的名称，则所有代码都是动态 SQL。那更难维护。
• 维护。当有无数个相似的表时，添加一个列或索引是非常困难的。
• 分析。当类似的数据通过表格传播时，真的很难回答“哪个客户的产品最多？”这样的问题。
• 安全。授予对一组表的访问权限比在无数表上更不容易出错。

毫无疑问，我错过了一些原因。您可以看到，拥有一个包含少量表的单个数据库几乎是轻而易举的事。

在某些情况下可能需要单独的数据库。我想不出一个很好的理由在单个数据库中为每个客户端设置单独的表。

第一个原因是安全和隔离。将数据存储到“物理上”独立的数据库中可能有商业或什至法律原因，以进一步减少一个客户看到另一个客户数据的可能性（意外或通过黑客攻击）。

另一个原因是客户是否有定制的解决方案。也就是说，有每个客户端的自定义。我仍然倾向于尝试将其放入单个数据库解决方案中，但这可能是不可能的。

与此相关的是您打算在云中和本地都支持的应用程序。在这种情况下，每个客户端单独的数据库可能会简化应用程序设计。

但是，一般来说，您会将数据存储在一个非常规范的单一数据库中，每个实体有一个表。