关于数据库关系和外键的最佳实践答案

【问题标题】：Best practices about database relation and foreign keys关于数据库关系和外键的最佳实践
【发布时间】：2016-06-30 13:21:47
【问题描述】：

假设User 可以请求Service，并且许多Providers 可以生成Offer。然后User 将选择一个Offer 并为其创建一个Transaction。

这是表格：

User:
-id
-name
-address

Service:
-id
-userId
-name
-description

Provider:
-id
-name
-url

Offer:
-id
-serviceId
-providerId
-price
-details
-transactionId

Transaction:
-id
-date
-status (completed, pending etc)
-method (paypal, direct credit card etc)

好的，所有表格都有链接，我们可以加入以查找任何内容。但我的问题是：即使我可以加入表格来获取buyerId和sellerId，在交易中存储buyerId（用户）和sellerId（提供者）是否有意义？

【问题讨论】：

如果 Transaction 不包含他们的 ID，你将通过哪些字段加入 Provider 和 User？
用户链接到服务，提供者链接到报价，服务链接到报价，报价链接到交易
我认为服务具有 UserId 是没有意义的 - 服务可以存在而不与任何用户相关。 Offer 和 Transaction 之间的关系似乎倒退了：如果没有 Transaction，Offer 上的transactionId 将为 NULL。
由于表中存储了多个用户，因此我将其称为users 而不是用户。（还有services、providers 等）

标签： mysql sql database-design relational-database database-schema

【解决方案1】：

当然没有意义。如果您有办法进行连接并获得结果，则永远不要将这些额外的列放在表上。因为它将是多余的，并且可能会导致错误。

如果您需要在涉及事务表的查询中获得出色的性能，只需制作好的索引，但（几乎）永远不要添加不必要的列。

在这里阅读更多： https://en.wikipedia.org/wiki/Denormalization

【讨论】：

好的，我只是想确认一下.. 我从不添加多余的列，但有时我只是认为，当您一遍又一遍地使用关系时，进行连接的成本很高。
这是有代价的，但如果你没有SUPER大的桌子，就不需要添加多余的信息。如果您遇到性能问题，可以考虑使用冗余工具....但首先您可以尝试很多不同的方法

【解决方案2】：

我建议使用不同的架构：

User (id, name, address)

Service (id, name, description)

Provider (id, name, url)

Offer (id, userId, serviceId, providerId, price, details)

Transaction (id, offerId, date, status, method)

要约将用户、服务和提供商结合在一起，交易是要约的后续行动。

假设用户将从多个优惠中进行选择，仅为一个优惠创建交易。
此外，一个提供商可以每次以较低的价格向同一用户提出同一服务的多个要约。

【讨论】：

我同意你的观点，但Service 是由User 创建的。每个用户都可以请求不同类型的Service，所以我认为userId 在Service 中是有道理的。
此外，系统将在以后扩展提供其他内容...考虑Service 为Service1 和Offer 为Service1_Offer 和后来Service2 和Service2_Offer 与所有使用相同的Transaction 表。所以我认为最好将transactionId 存储在Offer 表中。对吗？
不，offerId 必须转到 Transaction 表 - 否则您需要先创建 Transaction，然后才能创建有效的 Offer。要约不得了解交易，因为它可能永远不会与交易相关。
关于具有userId 的服务实际上取决于您对服务的定义。您的服务是否真的与一个用户相关联，即一对一的关系？特别是因为提供商将提供服务（据我了解您的业务案例）。
更正：在您的解决方案中，用户与服务的关系当然是一对多的（不是我之前评论中所说的一对一）。