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

时间:2016-03-15 08:07:05

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

假设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(提供者)存储在交易中是否有意义?

2 个答案:

答案 0 :(得分:1)

当然没有意义。如果您有办法进行连接并获得结果,则不应将此附加列放在表中。因为它会冗余,并且可能会导致错误。

如果您在涉及事务表的查询中需要出色的性能,只需制作好的索引,但(几乎)从不添加不必要的列。

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

答案 1 :(得分:1)

我建议使用不同的架构:

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)

要约将汇集用户,服务和提供商,交易是要约的后续行动。

考虑用户将从多个要约中选择,仅为一个要约创建交易 此外,一个提供商可以每次以相同的价格向同一用户提出同一服务的多个优惠。