【问题标题】:Payment table that has origin of the sales, orders or no有销售、订单或无来源的付款表
【发布时间】:2014-02-07 19:05:55
【问题描述】:

组织此付款表的最佳方式是什么:

现在这是我的付款表:

付款表

  • PaymentID(主键)
  • 类型(ENUM -> 订单、销售、付款)
  • Order_id(与 Orders 表相关)
  • Sale_id(与 Sales 表相关)

例子:

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

所以,问题是:我的表格结构是否正确?因为如果我需要进行维护,那将是一个问题。

【问题讨论】:

  • 当一笔付款应用于多个订单时,你会怎么做;仅适用于部分订单的付款呢?如果您有部分付款,然后是适用于该部分付款订单的部分付款,以及其他三部分怎么办?付款和订单之间的关系需要在一个单独的表中,例如“PaymentAllocation”,以便您可以处理任何可能的分配。还要考虑到人们不为订单付款,他们根据可能包含多个订单的发票付款,而您根本没有对此进行建模。

标签: mysql sql foreign-keys


【解决方案1】:

假设ids 都具有相同的类型,则您的结构是多余的。尽管如此,你的可能还不错。还有其他选择:

你可以这样做:

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)。

【讨论】:

  • 第一种选择会很好,但由于外键关系我不能使用..谢谢兄弟。
【解决方案2】:

我认为你的设计是不完整的。考虑:

  • 当一笔付款应用于多个订单时,您会怎么做
  • 仅适用于部分订单的付款怎么办
  • 如果您有部分付款,然后是适用于该部分付款订单的部分付款,以及其他三个,该怎么办?

付款和订单之间的关系需要在单独的表中,例如“PaymentAllocation”,以便您可以处理任何可能的分配。还要考虑到人们不为订单付款,他们根据可能包含多个订单的发票付款,而您根本没有对此进行建模(除非“销售”真的是“发票”)

您至少需要:

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)

请注意,没有将付款分配给订单。付款分配给销售(发票)。

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

【讨论】:

  • 哦,我知道部分付款,然后是适用于部分付款订单和其他三个的部分付款。在我的应用程序中,我正在考虑进行总和,如果总和相等到订单价格,所以它被支付了。
猜你喜欢
  • 2014-12-13
  • 2016-07-16
  • 1970-01-01
  • 2012-05-01
  • 2018-08-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多