数据库中用户和购买之间的关系答案

【问题标题】：Relationship between User and Purchases in a Database数据库中用户和购买之间的关系
【发布时间】：2015-03-16 08:54:58
【问题描述】：

我对数据库设计比较陌生，我在某个概念上遇到了一些麻烦 -

据我所知，关系数据库应该始终将信息分开，并且永远不要有重复的信息。

我正在创建一个简单的网站，用户可以在其中购买产品。这两个表可能看起来像这样：

用户：

产品：

如何在这两个表之间建立关系，以便多个用户可以拥有相同的产品而不使用数组？我想到的唯一解决方案是创建第三个名为“UserOwnership”或类似名称的表，每个user_id 的外键对应每个product_id 的外键。但是，我认为这不是一个好主意，因为所有用户都会在一个庞大的数据库中拥有无组织的条目，如下所示。

例如，user1 同时拥有product1 和product2。但是，所有其他后续用户都存储在同一个表中，我认为如果有足够的用户，这会变得混乱且无法使用。

我的另一个解决方案是为每个用户使用与产品 ID 对应的信息列表，例如：

user1 拥有 product1 product2 和 product3。这看起来效果很好，但它违反了在一个单元格中存储多个值的规则。

我该如何解决这个问题？

【问题讨论】：

据我所知，由于 users 表和 product 表是多对多的关系，所以除了在两个表之间使用关系表之外没有其他解决方案。在数据库设计中，当你有这种关系时，你应该有第三个表来链接它们。我不会推荐您的第二种解决方案，因为它的设计很糟糕。例如：如果您查询用户拥有 product_id=2 的所有用户，则与第一个设计相比，第二个设计的效率会更低。

标签： database-design

【解决方案1】：

您的第一个建议是许多人决定做的事情。一个 UserProductAssociationtable，其中每个 User-Product 关联都有一行，以及 User 和 Product 表的 FK。

【讨论】：

这是一个可扩展的解决方案吗？如果我有数以万计的用户，我能否在可接受的时间内扫描整个表？我理解为什么我的第二个解决方案是错误的 - 但由于我只需要查看每个用户拥有的产品，因此以某种方式将这些信息包含在个人用户中对我来说是有意义的。
@AlexanderLozada ：不，它不是可扩展的。但这是正确
那么有没有两者兼得的解决方案？如果我听起来很愚蠢，请原谅我，我不是很精通这一切的机制。

【解决方案2】：

在您处理购买的情况下，您很可能希望跟踪交易的详细信息，例如时间、用户帐户、产品、支付金额等。因为购买与用户或产品本身，他们可以有自己的表，主键是订单号，或者由用户ID和产品ID组成的复合键（假设每个用户只能购买一次相同的产品）

http://i.stack.imgur.com/3qkPH.png

这样，您可以使用购买表来查找使用 UserID 的用户拥有哪些产品，或者哪些用户拥有某个产品。

【讨论】：

【解决方案3】：

像你一样使用关联是一个很好的解决方案，性能应该没问题。

如果您帮助关系数据库管理系统，则每次都扫描整个表。由于关联表的主键是(user_id, product_id) 对，这并不是真正有用的，因此您可以在每个关联列user_id 和product_id 上创建索引。可以这样想：单个用户不太可能占关联表中所有行的 5% 以上，并且索引将允许 RDBMS 快速将搜索范围缩小到仅像 O(记录 n) 时间。如果您有 10 亿用户，数据库只需大约 30 个步骤即可找到给定用户购买的产品的行。

索引确实会增加开销，所以不要把它们放在任何地方！如果您想了解更多有关利弊的信息，Postgres documentation 对索引进行了精彩的讨论。

【讨论】：