建模发票和订单

Question

我在为包含订单和发票的数据库建模时遇到问题。实际上，从业务的角度来看，这更像是一个问题，但它仍然与数据库建模有关。

Orders表的模型：

现在我有另一个名为 payment_deadline 的专栏，里面有付款截止日期。我在想的是，我的 Orders 表应该有什么信息，我的 Invoices 表应该有什么信息？

哪一个有员工和客户 ID？哪个有价格？哪一个有付款信息？哪一个有截止日期？我完全迷路了。

我了解在商业世界中，订单表示货物供应商必须采取行动，发票表示货物供应商已履行其职责，客户现在必须支付货物/服务费用。但是我不知道如何在数据库中对其进行建模。任何见解都非常感谢。

Answer 1

你的问题太多太广提供任何特定的表设计建议。只是这个，“哪个有员工”，可能意味着Neil McGuigan的回答中提到的几十件事中的任何一个：第一个接听客户咨询电话的人，回复的销售人员，填写销售订单的销售助理，确认收到销售订单的生产经理，生产工作订单上项目的工人，等等。

但我会给你一个简单的概述，它可能会提供你所要求的一些见解。

业务交易生命周期

使用维基百科的定义，供应商-客户的通常工作流程如下图所示。颜色的意思：

• 粉红色项目 = 没有文件的客户-供应商联系/交互
• 蓝色项目 = 来自/给客户的文件
• 黄色项目 = 供应商内部的文件。

在咨询销售人员（可选）后，客户向供应商提交采购订单，准确描述他们决定购买的服务/产品。如果供应商接受，则建立具有法律约束力的合同。

该销售订单是由供应商的销售人员产生的，反映了采购订单的内容，但使用的是有意义的供应商的内部员工格式和行话。

供应商的内部员工、与生产相关的经理（高级工匠、制造经理、仓库主管等）创建一份或多份工单文件，指导他们的员工如何提供客户所需的服务/产品。

当采购项目的任何部分或全部已提供给客户时，供应商会准备发票并将其交付给客户以要求付款。发票应参考采购订单编号/ID。

最后，客户连同某种参考发票号码/ID的汇款通知一起付款。此步骤完成交易（忽略退货、变更单或其他问题）。

上图不是表格或实体图。例如，一个销售订单可能有多个工作订单。如果向客户进行部分交货，您可能会有多张发票。或者，想象一下如果制造人员一次只构建两个WonderWidget单元以避免浪费。所以我们必须等待另一个客户订购第二个小部件，而在等待时我们还没有产生工作订单。同时，我们可以开始处理销售订单上的其他项目，并为这些早期项目生成工单。在这个场景中，我们有一个多对多的关系，其中任何销售订单都可以有多个工作订单（客户想要几个项目，其中一些项目正在等待WonderWidget生产开始），而每个工作订单可以附加多个销售订单（在双WonderWidget生产的情况下，来自不同客户的一对销售订单）。

面对面零售

面对面零售要简单得多，工作流程包括三个即时步骤，其中只有两个是文档（或数据库实体）。

客户从商店货架上拿一些东西，在收银台展示，收银机记录物品（类似于销售订单），执行付款，并生成销售收据。销售收据基本上是收银机的理货（销售订单）加上付款详细信息（部分信用卡号、日期时间等）的组合。

同样，这被简化了，因为我们忽略了退货和此类问题。

同样，此图不是表格或实体图。

网络/电话零售

对于在线网络或电话订购，工作流程可能是上述两者的组合。如果客户立即付款，那么我们不需要发票和汇款通知书。如果是小商店，销售订单和工作订单可能是同一个实体，而如果这是具有多个仓库的 Amazon.com 风格的业务，那么我们将有多个工作订单。

过度简化的部分表格图

只是为了让您对桌子设计的新手有所了解，这里有一个非常简单的设计。部分设计，仅针对销售订单。此图使用简单的鱼尾纹符号和Postgres 数据类型。缩写：pk表示主键，fk表示外键。

Answer 2

价格不应该出现在您的订单表中。销售订单有许多行项目。价格属于行项目。交货日期也是如此。

发票是付款请求。一个订单可以有许多（或没有）发票，并且一张发票可以用于许多订单。这是多对多的关系。

如果您进行先付款后发货（或者不提供订阅服务），则实际上并不需要发票。

请查看此处的参考资料：即用型数据库模型示例。西尔弗斯顿在订购模型方面做得很好。

订单中可能涉及多个员工：委托销售人员、订单接受者等。以及多个客户：下订单的人、实际使用产品/服务的人、支付订单的一方、以及发货方。

例如，奶奶可以打电话给小苏西下订单。爷爷付钱。订单已发送给妈妈。