有關數據庫關係和外鍵的最佳做法

假設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（提供者）存儲在事務中？

來源

2016-03-15 user2707590

如果交易不包含其ID，您將通過哪些字段加入供應商和用戶？ – Filburt

用戶鏈接到服務，提供商鏈接到報價，服務鏈接到報價，並提供交易 – user2707590

我不認爲這是有道理的服務有一個UserId - 服務可以存在，而不會與任何用戶相關。 Offer和Transaction之間的關係看起來很落後：如果沒有Transaction，則Offer上的transactionId將爲NULL。 – Filburt

當然它沒有意義。如果您有辦法進行連接並獲得結果，則不應將此額外的列放在表格中。因爲它會是多餘的，並且可能會導致錯誤。

如果您在涉及事務處理表的查詢中需要很好的性能，只需創建好的索引，但幾乎不會添加不必要的列。

更多在這裏閱讀： https://en.wikipedia.org/wiki/Denormalization

來源

2016-03-15 08:31:01 Tirma

好吧，我只是想確認..我從來沒有添加冗餘列，但有時我只是認爲，當你將一遍又一遍地使用關係時，使連接是昂貴的。 – user2707590

它有成本，但是如果你沒有SUPER大表，就不需要添加冗餘信息。如果你有性能問題，冗餘是一個你可以考慮的工具....但首先你可以嘗試很多不同的東西 – Tirma

我建議一個不同的模式：

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)

的發售將彙集用戶，服務和供應商和交易是後續報價。

考慮到用戶將從多個要約中選擇，僅爲一個要約創建交易。
另外，一個提供商可以每次以降低的價格向同一用戶提出針對相同服務的多個提議。

來源

2016-03-15 09:52:43 Filburt

我同意你的看法，但'服務'是由'用戶'創建的。每個用戶都可以請求不同種類的'Service'，所以我認爲'userId'在'Service'中是有道理的。 – user2707590

此外，系統將在稍後擴展提供其他內容......考慮將Service作爲Service1和提供作爲Service1_Offer，然後將Service2和Service2_Offer全部使用相同的事務表。所以我認爲'transactionId'存儲在'Offer'表中更好。對？ – user2707590

不，offerId必須轉到交易表 - 否則，您需要創建一個交易，然後才能創建有效的優惠。優惠不得知道交易，因爲它可能永遠不會與交易相關。 – Filburt

有關數據庫關係和外鍵的最佳做法

回答

相關問題