在數據庫中處理退款或/存儲信用的最佳方式？

比方說，我有一個Web應用程序是某種商店。我有一張表，可以存放所有的貨幣交易。在數據庫中處理退款或/存儲信用的最佳方式？

客戶ID，訂單ID，支付金額...等

而這個表被用於銷售報告和你有什麼。

現在我們要給客戶一種類似的禮物，無論是禮券還是退款。

只用一個-amount將它輸入到同一個表中是一個壞主意？還是把它們放在另一張桌子裏更好？

是否有一個主要的缺陷，在設置網站的這個表結構開始？

我已經建立了一些這樣的系統，但沒有太多的其他人的反饋，你們通常如何設置你的表像數據庫的商店。

感謝，肯

來源

2010-10-22 kennethj

通常會有一個原因，你會給予退款，所以已經用於該用途的情況下，模式是比購買的不同。

那麼現在您的選擇是否應該在兩個地方存儲退款？有多個事實來源總讓我感到不舒服。

您需要決定如何解決客戶的整體平衡問題，將存儲在多個地方的存儲/存儲將會比本應該更難。所以，你回到有一個單一商店的錢進/出和一個單獨的存儲元數據關於退款。

Purchase 
-------- 
PurchaseId 
ItemId 
CustomerId 
Payment 

Refund 
------ 
PurchaseId 
Reason

顯然還有其他領域，像你說的退款

-ve值碰巧這是一個更接近真實世界的紙臺賬和獨立的「退款」的書。

我從來沒有做到這一點，這只是我想大聲:-)

來源

2010-10-22 18:34:30

有上百種方法對皮膚一隻貓，但這裏有幾個「思考的食糧」要點：

您可能會添加一個「退款」列，如果是退款，則包含「1」或銷售「0」。然後，您必須決定是否將所有金額都保留爲正值（如果退款列中存在「1」，則只需將其相減），或者如果您希望金額爲正值和負值，並且只需查看退款列即可的指標（可能用於報告目的）
你應該考慮你的購買ID！你認爲它更多是「交易ID」還是「訂單號碼」？看起來似乎起初沒有區別，但交易ID對於每個條目都有唯一的ID，這意味着購買將是0000，退款將是0001（例如）。如果您將其作爲訂單編號處理，則購買將爲0000，並且退貨也將爲0000，以便您知道退款與該特定目的有關。
擴展我以前的觀點，我會建議考慮一個單獨的Refund表，其中包含一個唯一的RefundID，CustomerID，OriginalPurchaseID，ItemID，Amount和Reason列（也許PaymentMethod）。您的銷售表格將保持幾乎相同：（唯一）PurchaseID，CustomerID，ItemID，Amount，PaymentMethod。此外，請注意您的ItemID，因爲當前的設置需要爲每個itemID單獨輸入（具有重複購買ID）。

希望這有助於一點點，並可以引導你到一個更好的結構。不要害怕有多張桌子，只要確保你有一個很好的方法來關聯他們！

來源

2010-10-22 19:48:54

我只是擔心，有多個表時，你可以擺脫一個讓事情變得更慢，更復雜的代碼。把它放在一張桌子裏有什麼問題？我當然認爲orderid和交易ID是不同的，那麼是否有一個問題，將它全部放在一個表中，其數量和可能的重複訂單ID都爲負值。或在禮品券新的orderids負數的情況下。 – kennethj 2010-10-22 21:35:30

也跟蹤訂單項目，我明確需要跟蹤每個項目的價格，當它被命令。人們傾向於有一個物品表，然後另一個訂購物品的表格，其中包含物品在購買時的價格以及與orderid相關的外鍵，然後在這種情況下將所訂購的物品數量加起來交易表中的金額相等......這似乎是多餘的。這通常如何處理？也許我應該尋找一些更受歡迎的購物車，看看它是如何完成的。 – kennethj 2010-10-22 21:38:25

2個小表可以比1個大表快速搜索。特別是如果你知道你正在尋找一個銷售或回報（你可能會立即知道）！如果您確實需要從兩者中提取，則只需加入sale.purchaseID = return.originalPurchaseID上的表即可。就像我在我的回答中所說的那樣，不要害怕有多個表如果（只有）如果你正確地構造和關聯它們。很多時候，多張桌子變成噩夢的原因是因爲沒有提前想到。你似乎現在正在避免這個錯誤，所以你應該很好！ – 2010-10-23 03:35:35

在數據庫中處理退款或/存儲信用的最佳方式？

回答

相關問題