支付交易和訂單表？

Question

處理支付交易到數據庫的最佳方式是什麼？

這裏是我想出了：

訂單表

• 訂單ID（主鍵）**
• MEMBERID（FK）
• 的OrderTotal
• 狀態（待定，加工 已完成）
• 已付（0，1）

付款表

• PaymentID（主鍵）
• 訂單ID（與訂單表）
• 日期
• 事務狀態

例如，如果有兩筆付款交易付款表中的OrderID-123。

一是下降和另一種是Sucesss

如果Sucesss的一排，然後Orders.Paid將成爲1

或什麼是更好的解決方案？

Answer 1

根據我的經驗，拒絕和成功是不夠的。在豐富多彩的使用案例中，您可能會遇到成功支付，包括清理資金（例如電子支票），退款（由您提供），逆轉（由客戶/ api提供商提供），部分退款/逆轉（例如狗的玩具，但不是他的食物，在相同的順序），扭轉退款/逆轉。

更不用說訂閱固有的各種其他情況，例如，訂閱升級和降級，訂閱更改，取消，取消取消，鎖定，以及沒有。

不用說，問題就變得如果你需要處理的會員費，用戶少的發票，不同的計費/航運接觸，經銷商甚至更爲棘手，等

精確的答案取決於您的具體要求，很明顯，但我發現，從滿足T分類賬會計準則的模型開始（比如借記卡/賬戶圖表），您幾乎總是會變得更好，然後朝着您的特定產品努力。