mat*_*yah 7 mysql normalization database-design transaction
我在为包含订单和发票的数据库建模时遇到问题。实际上,从业务的角度来看,这更像是一个问题,但它仍然与数据库建模有关。
Orders表的模型:
现在我有另一个名为 payment_deadline 的专栏,里面有付款截止日期。我在想的是,我的 Orders 表应该有什么信息,我的 Invoices 表应该有什么信息?
哪一个有员工和客户 ID?哪个有价格?哪一个有付款信息?哪一个有截止日期?我完全迷路了。
我了解在商业世界中,订单表示货物供应商必须采取行动,发票表示货物供应商已履行其职责,客户现在必须支付货物/服务费用。但是我不知道如何在数据库中对其进行建模。任何见解都非常感谢。
你的问题太多太广提供任何特定的表设计建议。只是这个,“哪个有员工”,可能意味着Neil McGuigan的回答中提到的几十件事中的任何一个:第一个接听客户咨询电话的人,回复的销售人员,填写销售订单的销售助理,确认收到销售订单的生产经理,生产工作订单上项目的工人,等等。
但我会给你一个简单的概述,它可能会提供你所要求的一些见解。
使用维基百科的定义,供应商-客户的通常工作流程如下图所示。颜色的意思:
在咨询销售人员(可选)后,客户向供应商提交采购订单,准确描述他们决定购买的服务/产品。如果供应商接受,则建立具有法律约束力的合同。
该销售订单是由供应商的销售人员产生的,反映了采购订单的内容,但使用的是有意义的供应商的内部员工格式和行话。
供应商的内部员工、与生产相关的经理(高级工匠、制造经理、仓库主管等)创建一份或多份工单文件,指导他们的员工如何提供客户所需的服务/产品。
当采购项目的任何部分或全部已提供给客户时,供应商会准备发票并将其交付给客户以要求付款。发票应参考采购订单编号/ID。
最后,客户连同某种参考发票号码/ID的汇款通知一起付款。此步骤完成交易(忽略退货、变更单或其他问题)。
上图不是表格或实体图。例如,一个销售订单可能有多个工作订单。如果向客户进行部分交货,您可能会有多张发票。或者,想象一下如果制造人员一次只构建两个WonderWidget单元以避免浪费。所以我们必须等待另一个客户订购第二个小部件,而在等待时我们还没有产生工作订单。同时,我们可以开始处理销售订单上的其他项目,并为这些早期项目生成工单。在这个场景中,我们有一个多对多的关系,其中任何销售订单都可以有多个工作订单(客户想要几个项目,其中一些项目正在等待WonderWidget生产开始),而每个工作订单可以附加多个销售订单(在双WonderWidget生产的情况下,来自不同客户的一对销售订单)。
面对面零售要简单得多,工作流程包括三个即时步骤,其中只有两个是文档(或数据库实体)。
客户从商店货架上拿一些东西,在收银台展示,收银机记录物品(类似于销售订单),执行付款,并生成销售收据。销售收据基本上是收银机的理货(销售订单)加上付款详细信息(部分信用卡号、日期时间等)的组合。
同样,这被简化了,因为我们忽略了退货和此类问题。
同样,此图不是表格或实体图。
对于在线网络或电话订购,工作流程可能是上述两者的组合。如果客户立即付款,那么我们不需要发票和汇款通知书。如果是小商店,销售订单和工作订单可能是同一个实体,而如果这是具有多个仓库的 Amazon.com 风格的业务,那么我们将有多个工作订单。
只是为了让您对桌子设计的新手有所了解,这里有一个非常简单的设计。部分设计,仅针对销售订单。此图使用简单的鱼尾纹符号和Postgres 数据类型。缩写:pk
表示主键,fk
表示外键。
价格不应该出现在您的订单表中。销售订单有许多行项目。价格属于行项目。交货日期也是如此。
发票是付款请求。一个订单可以有许多(或没有)发票,并且一张发票可以用于许多订单。这是多对多的关系。
如果您进行先付款后发货(或者不提供订阅服务),则实际上并不需要发票。
请查看此处的参考资料:即用型数据库模型示例。西尔弗斯顿在订购模型方面做得很好。
订单中可能涉及多个员工:委托销售人员、订单接受者等。以及多个客户:下订单的人、实际使用产品/服务的人、支付订单的一方、以及发货方。
例如,奶奶可以打电话给小苏西下订单。爷爷付钱。订单已发送给妈妈。
归档时间: |
|
查看次数: |
12385 次 |
最近记录: |