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

Question

假设 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（提供者）是否有意义？

Answer 1

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

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

在此处阅读更多内容： https://en.wikipedia.org/wiki/Denormalization

Answer 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)

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

假设用户将从多个报价中挑选，只为一个报价创建交易。
此外，一个提供商可能每次都以较低的价格向同一用户提供同一服务的多个报价。

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

Best practices about database relation and foreign keys

mysql

sql

database-design

relational-database

database-schema