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