订单/发票/付款数据库建模

Posted 2023-02-15

【中文标题】订单/发票/付款数据库建模

【英文标题】：Order/Invoice/Payment database modeling

【发布时间】：2015-05-05 21:09:14

【问题描述】：

我正在设计一个具有以下场景的电子商务网站：

客户可以购买商品并创建订单。 订单可能有未知费用，将在客户之后添加 支付项目的总金额。也就是说，客户支付 先一定数量。该订单增加了一些费用并更改了总额。 客户再次支付差价。但是这两个（或 更多）付款与同一订单相关联。 （可选）客户可以为多次提交单笔付款 订单。

目前，我有一个Order 表，每个订单可能包含多个OrderLineItems（简化架构）：

Order
=====
customer
line_items
total
status

OrderLineItem
=============
price
quantity
order
product

付款与订单相关联（简化模式）：

Payment
=======
order
payment_account
total
result

目前的实现似乎很难支持单个订单场景的多次付款。我认为我必须在系统中引入不可变的发票，并且付款应该与发票而不是订单相关联。但是，对于上述场景，我需要一些关于订单/发票/付款建模的帮助。我有一些具体问题：

订单和发票看起来与我非常相似（例如，两者都有 项目和总数）。典型的主要区别是什么 电子商务系统？ 我应该如何为我的方案建模发票？我应该有 OrderLineItems 代表 Order 和 InvoiceLineItems 代表 Invoice？ 一些初步想法：我将关联多张发票 有一定的顺序。每当订单更改总数时，我都有 以某种方式计算差异并发送新的/不可变的发票 给客户。然后，客户可以付款，付款将是 与发票相关联。

很想听听一些建议。非常感激。谢谢！

【问题讨论】：

付款和发票是多对多的。用户可以在一张发票上进行多次付款，也可以对多张发票进行一次付款。您需要一个政策（业务规则）来确定如何根据公司规则应用付款

@sqlvogel 你能推荐几个吗？我愿意尝试一些灵活且易于与我们的后端集成的软件包，也许是 Mongo。谢谢！

@NeilMcGuigan 是的。我在这方面没有太多经验，想了解更多关于现有系统如何解决这个问题的信息。你有什么推荐的资源吗？谢谢！

【参考方案1】：

这里有很多问题，我会尽量解决。很多问题是业务模型而不是数据模型。

首先，您需要一张不可变发票是对的。创建发票后，您将无法更改它，处理发票更改的标准方法是开具贷方通知单和新发票。

考虑表之间的关系：Order 不需要保存lineItems，因为它们以其他方式引用，即

Order
=====
orderId
customerId
status

OrderLineItem
=============
orderLineItemId
orderId
product
price
quantity

所以要查看订单，您可以在 orderId 上加入表格。也不需要存储total，因为它是根据连接计算得出的。

尽量不要重复您的数据：您的发票将引用orderLineItems，但不一定与订单中的相同。例如，客户订购了 A 和 B，但 B 缺货。您运送 A 并为 A 创建引用 orderLineItemId 的发票。因此您的发票表可能如下所示：

invoice
=======
invoiceId
status

invoiceLineItem
===============
invoiceId
orderLineItemId
quantity

换句话说，不需要知道项目的详细信息。您可能想知道为什么不只是将 invoiceId 添加到 orderLineItem 表中 - 原因是客户可能订购了 10 件商品 A，但您只运送了其中 8 件，另外两个将在后续发票上进行。

付款不是针对订单，而是针对发票。因此，您的付款表应该引用 invoiceId。

然后你谈到和解。如果一切都很完美，客户将根据特定发票付款，即使是部分付款。实际上，这将是您最头疼的问题。假设客户有几张金额为 x、y 和 z 的未结发票。如果他们支付 p，你将它分配给哪个？也许按日期顺序，因此如果 p>x，则剩余部分分配给 y。如果 p=z 怎么办？也许客户现在打算支付 z 但正在争论 y 并且放错了 x？你如何处理这些事情取决于你，但我可以说大多数发票系统确实做得很糟糕。

【讨论】：

非常感谢。这很有帮助。我在设计这个方面几乎没有经验，我想我理解您所说的“它们与业务模型而不是数据模型更相关”的意思。但我想知道我是否正朝着一个奇怪的方向前进。那么，拥有一个 orderLineItem 和一个单独的 invoiceLineItem 模型是否完全正常？它们有何不同取决于业务逻辑？

我目前正在为餐厅 POS 系统开发订单/发票系统。你的回答很有帮助。但是我有一个问题：为什么不将字段quantity_fulfilled 添加到OrderLineItem 以用于实际交付的订单，而不是创建invoiceLineItem 表？

@angel 晚了一年，但这是因为每个订单可能有多个发票（每个订单行项目有多个发票行项目）。我什至会在此处添加一个单独的映射表（order_invoice），以允许关系是多对多的，即每个订单有多个发票，每个发票有多个订单。