付款交易和订单表？
处理数据库支付交易的最佳方式是什么？
以下是我的想法：
订单表
- OrderID（主键）**
- MemberID (FK)
- OrderTotal
- 状态（待处理、处理中） 已完成)
- 已付款 (0, 1)
付款表
- PaymentID（主键）
- OrderID（与 Orders 表相关）
- 日期
- 交易状态
例如，如果 Payments 表中有两笔来自 OrderID-123 的付款交易。
一个是拒绝，另一个是成功
如果有一行成功，那么Orders.Paid会变成1
或者什么是更好的解决方案？
What is the best way to handle payment transactions to the database?
Here is what I came up with:
Orders Table
- OrderID (primary key)**
- MemberID (FK)
- OrderTotal
- Status (Pending, Processing
Completed) - Paid (0, 1)
Payments Table
- PaymentID (primary key)
- OrderID (related to Orders table)
- Date
- Transaction Status
For example, if there is two payment transactions from OrderID-123 in the Payments table.
One is Decline and other one is Sucesss
If there is a row of Sucesss, then Orders.Paid will become 1
Or what is better solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
以我的经验来看，衰落和成功还不够。在丰富多彩的用例中，您可能会遇到等待资金清算的成功付款（例如电子支票）、退款（由您进行）、冲销（由客户/API 提供商进行）、部分退款/冲销（例如狗的玩具，但不是他的食物，在同一订单内），撤销退款/撤销。
更不用说订阅固有的各种其他情况，例如订阅升级和降级、订阅更改、取消、取消取消、锁定等等。
不用说，如果您需要处理附属付款、无用户发票、不同的计费/运输联系人、经销商等，问题会变得更加棘手。
显然，确切的答案取决于您的具体要求，但我发现您几乎总是最好从满足 T 型分类帐会计严格要求的模型（即带有科目表的借方/贷方）开始，然后逐步开发您的特定产品。
Decline and success are not enough in my experience. Among colorful use-cases, you may experience successful payments pending clearing of funds (e.g. e-checks), refunds (made by you), reversals (made by the customer/api provider), partial refunds/reversals (e.g. the dog's toy but not his food, within the same order), reversed refunds/reversals.
Not to mention the variety of other cases inherent to subscriptions, e.g. subscription upgrades and downgrades, subscription changes, cancellations, cancelled cancellations, locked, and what not.
Needless to say, issues become even thornier if you ever need to deal with affiliate payments, user-less invoices, different billing/shipping contacts, resellers, etc.
The precise answer depends on your specific requirements, obviously, but I've found that you're almost always better off starting with a model that satisfies the rigors of T-ledger accounting (i.e. debit/credit with a chart of accounts), and then working your way up towards your specific products.