我可以使用什么数据库模式来保存不同类型的计费数据？

Question

我有一个创建订单的系统，该订单可以记入公司帐户、发送货到付款 (COD) 或记入信用卡。 我创建了下表：

订单
订单 ID
billingoption_id

计费选项
billingoption_id

我不确定应如何为计费数据构建下一个表。 我应该为每种类型的计费选项（即 COD、信用卡和 House 帐户）建立一个单独的表吗？ 那么我在 Orders 表上是否会有另一个外键列来引用帐单数据的记录？

Answer 1

您可以通过任何一种方式完成此操作：一个大的 billingoptions 表，其中包含包含所有类型的字段，对于不适用于给定类型的字段使用 NULL，或者一堆婴儿表父 billingoptions 表的“星号关闭”。 两者都有各自的优点和缺点。

对于大表来说，

• 可以在一个表中轻松引用所有数据是件好事。
• 跟踪外键依赖性并执行更新或插入是有效的。
• 但是您需要更改表结构以在将来添加新的计费选项，并且可能会存储无效的数据组合（例如，在同一记录中设置信用卡类型和 COD 标志）。

对于小型表，

• 数据被分区并密切反映程序的对象结构是件好事。
• 很高兴您可以添加新的付款选项或更改现有的付款选项，而不必担心影响其他选项。
• 这些关系非常明确。 您不会意外地将一笔存款与另一笔存款链接起来，因为外键要求将其与批准链接起来。
• 但是您最终会在设计中引入大量表，这需要大量 JOIN，导航起来可能会很痛苦，并且在插入和更新时效率不高。

在工作中，我们最终选择了小婴儿桌。 它看起来像这样：

Table Orders:
--> OrderId PK
--> (Lots of Other Fields)

Table Payments:
--> PaymentId PK
--> OrderId (FK) [There may be more than one payment per order]
--> PaymentType [Restricted field contains values like 
       'PAYPAL' or 'CREDIT', you use this to know which 
       baby table to look up that can contain additional 
       information]

Table PaymentsPayPal:
--> PaymentPayPalId PK
--> PaymentId FK points to Table Payments
--> TransactionNo
--> (Other PayPal specific fields)

Table PaymentsCheck:
--> PaymentCheckId PK
--> PaymentId FK points to Table Payments
--> RoutingNo
--> (Other e-check specific fields)

+ other tables for remaining payment types....

所有付款类型共享三个与交易相关的表：

Table PaymentApprovals:
--> PaymentApprovalId PK
--> PaymentId FK points to Table Payments
--> Status [Some flag meaning 'Succeeded', 'Failed', 'Reversed', etc]
--> ProcessorMessage [Something the service sent back, like '(M) CVV2 Matched']
--> Amount
--> (Other administrative fields)

Table PaymentDeposits:
--> PaymentDepositId PK
--> PaymentApprovalId FK points to Table PaymentApprovals
--> Status
--> ProcessorMessage
--> Amount
--> (Other administrative fields)

Table PaymentRefunds:
--> PaymentRefundId PK
--> PaymentDepositId FK points to Table PaymentDeposits
--> Status
--> ProcessorMessage
--> Amount
--> (Other administrative fields)

我们所有的付款方式（信用卡、PayPal、Google Checkout、支票、现金、商店信用和汇票）都被抽象以适应此批准 - -> 存款--> 退款比喻，UI 在具有不同实现的 IPayment 和 IPaymentProcessor 接口上调用相同的方法（Cyber​​sourcePaymentProcessor、PayPalPaymentProcessor > 等）。 在过去的一年半中，抽象在这些不同的方法中运行得很好，尽管有时 GUI 会向用户显示不同的措辞（例如，它会说“授权”和“收费”而不是“批准”和信用卡付款的“存款”，以及输入现金的屏幕一口气执行批准/存款步骤。）

希望这是有道理的。 听起来您实际上并未存储付款信息，但考虑这些信息最终会去哪里是很有用的。

Answer 2

专注于事物。 实际的事情。 首先尝试用自然语言简单、直接地描述事物。

然后，当您寻求设计指导时，您可以提供定义。 在某些情况下，编写定义的行为将使设计具体化。

订单就是事物。 订单有哪些属性？ 客户、产品、付款/计费选项。

结算选项（几乎）是事物。 显然，您可以定义和识别它们。 （我不确定我可以。从你的问题来看，你似乎可以。但是如果没有一句话总结，我不确定 Billion Options 是怎么回事。

什么是“账单数据？”什么？这是什么东西？它有什么属性（或属性）？

“账单数据”与订单有何关系？

请随意更新每个事物的定义。