Question

组织此付款表的最佳方式是：

现在这是我的付款表：

付款表

PaymentID（主键）
类型（ENUM - ＆gt;订单，销售，付款）
Order_id（与订单表相关）
Sale_id（与销售表相关）

示例：

PaymentID | Type    | Order_id | Sale_id
1         | Sale    | NULL     | 3
2         | Order   | 2        | NULL
3         | Payment | NULL     | NULL         << In this case, it references itself

所以，问题是：我的表格结构正确吗？因为如果我需要进行维护，这将是一个问题。

Answer 1

假设id都具有相同的类型，那么您的结构就是多余的。尽管如此，你的可能还不错。还有其他选择：

你可以这样做：

PaymentID (primary key)
Type (ENUM -> Order, Sale, Payment)
relatedto_id

缺点是您没有正确的外键关系。好处是你可以添加新类型而不改变表的结构。记录较小。

您还可以为每种类型设置单独的ID：

PaymentID (primary key)
Order_id (related to Orders table)
Sale_id (related to Sales table)

然后，您可以通过使用视图访问该表来对该类型进行估算。缺点是添加新类型需要修改表格，您必须归类该类型。好处是外键是对齐的。

你的结构很好。但是，使用MySQL的一个缺点是，您无法轻松地强制执行使列保持一致的表上的约束（因此“订单”类型始终具有非空order_id）。

Answer 2

我建议您的设计不完整。考虑：

付款适用于多个订单时，您打算做什么？
仅适用于部分订单的付款
如果您有部分付款，然后是适用于该部分付款订单的付款以及其他三个付款，该怎么办？

付款和订单之间的关系需要在单独的表格中，例如“PaymentAllocation”，以便您可以处理任何可能的分配。还要考虑到人们不支付订单费用，他们支付可能包含多个订单的发票，而你根本没有对此进行建模（除非“Sale”真的是“发票”）

您至少需要：

Order (Order Id, other order data)
Payment (Payment Id, other payment data independent of sale or order)
Sale (Sale Id, I'll assume this is really "Invoice")
PaymentAllocation(PaymentId, SaleId, AmountAllocated)

请注意，订单没有分配付款。付款分配给销售（发票）。

这只是一个粗略的框架，可以让您思考如何模拟计费和收集的现实。

具有销售，订单或否的原产地的付款表

2 个答案: