我有一个Invoices表，这些表是根据与Job或Order相关联的广告资源创建的。我可以将Quotes表作为库存和发票之间的中间位置，但感觉我会有重复的数据结构和逻辑来处理“这是引用吗？”位。
从业务角度来看，报价 与发票不同：报价在承诺之前发送，发票一旦完成并且付款到期就会发送，但如何在我的发票中表示存储库和模型。
修改：表示Job === Order。
答案 0 :(得分：16)
有三种方法：
将发票和报价存储在单独的表格中。
如果发票和报价重复的字段很少（或者使用带有3个表的选项＃3），并且如果它们之间存在1个或多个关系（对于1-1，请使用），这是一个很好的设计选项＃2）。
如果两者之间的“共享”信息在报价成为发票时实际上会发生变异，这也是一个很好的选择（尽管其中一些突变应该用单独的字段/表格妥善处理，例如应用折扣，等...）。
当多个报价变成单个（或多个）发票时，显然需要略微改变此选项。这会添加第3个表格，该表格是一组报价与发票（或发票组合，如果它变得那么复杂）之间的映射。
将它们存储在同一个表中，并带有额外标记“Invoice or quote”以及两个存储的额外字段。这可以通过不同行中的发票和报价来完成，也可以与它们共享行（标志也具有“两个”值）。
后者（同一行可以是发票和报价）是一个不错的选择如果它们被映射为1到1 ，并且很少有字段区分这两者。
前者（发票和报价单独的行）通常不是一个好的设计，而是使用＃3或＃1选项做得更好。
有3个表格，一个用于两者之间的公共字段，两个表格仅限发票和报价。
如果发票和报价被映射为1-1，或者它们是1-many但是许多发票中的每一个都具有完全相同的字段值，无论哪个字段是常见的，这都是一个不错的选择。否则，请使用＃1。
当多个报价转换为单个发票时，可以略微改变此选项。这会添加第4个表，它是一组引号和一个发票（或一组发票，如果它变得那么复杂）之间的映射。同样，这里的假设是所有引号和发票之间有相当大的共同信息链接/组合在一起，否则只需使用＃1。
答案 1 :(得分：8)
报价更类似于订单。我见过几个分销/零售系统，其订单表有一个名为IsQuote的布尔标志。这看似简单，因为将报价转换为订单变得微不足道。我从来不喜欢它，因为从引号中产生的订单并不总是完全引用。因此，像这样的系统会丢失可能有用的信息（即将报价与订单进行比较的报告）。因此，我更喜欢报价和订单表大致相同但又分开的系统。在分销系统中，这通常会导致OrderHeader，OrderLine（与项目/库存表相关），QuoteHeader和QuoteLine等表格。您可能还有一个表来建模关系，其中一个引用可以映射到多个订单。
发票通常来自订单。有时，单个发票上将收到多个订单。例如，在某些情况下，我看到公司每月都会向好客户收费。我还看到它以另一种方式工作，其中多个发货的大订单在多个发票上开帐单（每个发货一个）。
最后，付款通常与发票有多对多的关系。有时一笔付款包含多张发票。有时一张发票可以通过几笔付款获得支付。
答案 2 :(得分：3)
[单一产品和服务被忽略，为简单起见。]
销售报价是提案，可以将时间窗口（日期范围）内的商品出售给另一方。此资产尚不存在。您可以引用资产的规格（商品）。
报价应该在某个时候到期，并且可以在到期之前接受或不接受。
销售订单是承诺，可以将某个日期的商品出售给另一方。它可以从公认的报价中创建。
订单或报价可能包含付款条款，例如＆＃34;您可以在交货后30天向我们付款＆＃34;。
订单可能是针对尚未存在的商品（您销售商品，而不是资产）。也许你正在构建它。也许你会从其他人那里购买它。
销售订单会导致物理资产的采购（从库存中获取，制造或购买），然后是物理资产的货件，可能是可能不会在交货中结束。有时，客户会打电话给＃34;在供应商处提取资产。
一般而言，资产必须转移才能将订单行计为收入（这取决于您的运输条款，可能是在发货或交付时或在两者之间）。
销售订单可以取消（例如，某些行业有冷静期）。
销售发票是订购产品的付款请求。它可能在交货前，交货时或交货后发生，或者根本不发生（例如，如果在麦当劳排队）。订单可能包含一个或多个发票，发票可能包含多个订单。
发票有望导致一个或多个付款，已应用到帐户。付款通常会导致一个或多个付款收据。如果使用权责发生制会计，付款不一定与收入相同。
答案 3 :(得分：1)
我建议尽可能灵活。使用下表
工作表，发票表，报价表
在您的发票表和报价表中，存储作业ID，为其指定索引并创建外键约束。将聚集索引保留在报价ID和发票ID上。
答案 4 :(得分：1)
在我工作的最后一个系统上，报价和发票之间的唯一区别（就数据库而言）是表格上的一个标志，表明该报价是否已被客户接受（此时生成了另一个报表）所有相同的信息，除了它是发票而不是报价）