冗余数据还是两个查询？

Question

例如，一个保存信用卡费用的表、一个保存信用卡的表和一个保存用户的表。

每个费用恰好与一张卡相关联，并且每张卡恰好与一个用户相关联。用户可以在文件上有多张卡。

如果我将这些数据保存在MySQL数据库中的三个不同的表中，如下所示：

费用：

---------------------------------------------
id | card | amount | description | datestamp
---------------------------------------------
5  | 2    | 50.00  | Example     | 1369429422

卡片：

------------------------------------------------------------------
id | user | name       | number           | cvv2 | exp_mm | exp_yy
------------------------------------------------------------------
2  | 1    | Joe Schmoe | 4321432143214321 | 555  | 1      | 16

用户：

-------------------------------------------
id | first_name | last_name | email
-------------------------------------------
1  | Joe        | Schmoe    | joe@schmoe.co

现在，假设我想访问一个用户，并给出一个费用。为了找到用户，我必须首先查找与费用关联的卡，然后再查找与该卡关联的用户。显然，在这样的示例中，速度可以忽略不计。但在其他情况下，我认为这是两个查询。

但是，如果我像这样存储数据：

收费

----------------------------------------------------
id | card | user | amount | description | datestamp
----------------------------------------------------
5  | 2    | 1    | 50.00  | Example     | 1369429422

则该费用将直接与用户相关联。然而，这是冗余信息，因为相同数据存储在卡片表中。

有什么想法？

Answer 1

您不将用户信息包括在费用表中的直觉是正确的；但是，它仍然只有一个查询：

select first_name, last_name, email
from users, cards, charges
where users.id = cards.user
and cards.id = charges.card
and charges.id = 5;

这将为您提供id为5的费用的用户信息。这正是关系数据库最擅长的事情:)这种事情被称为“连接”，因为它将多个表连接在一起，为您提供所需的信息。有多种方法可以编写此查询。

顺便说一句，这可能是一个人为的例子，但如果这是一个从头开始编写的应用程序，那么有很多理由可以避免将信用卡存储在您自己的数据库中。通常，支付处理机可以为您处理细节，同时仍然允许您对信用卡进行充值。More info.

Answer 2

您可以通过将用户id添加到收费表中来进行反规范化。考虑到表的预期大小，您需要知道这是否必要。如果这种优化是必要的，那么就使用它。如果您不知道，请在将来根据需要进行优化。

尽管如此，您不需要两个查询

SELECT users.* FROM charges
JOIN cards ON charges.card = cards.id
JOIN users ON cards.user = users.id
WHERE charges.id = ?