1

例如，一个包含信用卡费用的表、一个包含信用卡的表和一个包含用户的表。

每笔费用仅与一张卡相关联，每张卡仅与一位用户相关联。一个用户可能有多个存档卡。

如果我将这些数据保存在 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

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

想法？

4

2 回答 2

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

顺便说一句，也许这是一个人为的例子，但如果这是您从头开始编写的应用程序，那么有很多理由避免将信用卡存储在您自己的数据库中。通常，支付处理器可以为您处理详细信息，同时仍允许您从信用卡中收取费用。 更多信息。

于 2013-05-24T20:35:31.660 回答
1

您可以通过将用户 ID 添加到费用表来进行非规范化。鉴于表格的预期大小，您需要知道这是否有必要。如果有必要进行此优化，请使用它。如果您不知道，则在将来根据需要进行优化。

就目前而言，您不需要两个查询

SELECT users.* FROM charges
JOIN cards ON charges.card = cards.id
JOIN users ON cards.user = users.id
WHERE charges.id = ?
于 2013-05-24T20:37:36.293 回答