database - 发票数据库设计

Question

几天前我创建了一个处理发票的应用程序。我想知道如何最好地将折扣整合到我的发票中。我应该把它作为一个负面项目（在 invoice_items 表中）还是应该在发票表中创建一个“折扣”列？

Answer 1

我会把它作为一个负值项目。原因是：

• 对于开票，计算值永远保持不变是非常重要的；即使您的计算公式稍后发生变化，您也可以正确复制任何给定的发票。如果当时计算的值不正确，这甚至是正确的——它就是这样。
• 具有价值金额意味着可以轻松处理针对特殊情况的手动调整 - 例如，您的营销经理/会计师可能会因为延迟交货而决定给予 100 美元的一次性折扣。这对于负值来说是微不足道的 - 只需添加另一行，但折扣率很困难/麻烦
• 每张发票可以有多个折扣金额
• 它是完全灵活的——它有自己的空间存在并成为它需要的任何东西。事实上，我会将折扣打造成另一种“产品”（甚至可能是多种产品 - 每个不同的折扣原因一个，例如圣诞节、优惠券、推荐等。
• 使用它自己的项目，您可以像任何其他“产品”一样添加原因描述 - 例如“支付现金 10% 折扣”或其他
• 您不需要任何特殊的代码或数据库列！只需像以前一样汇总项目并将它们打印在发票上。“没有勺子（折扣）”：这只是另一个项目——还有什么比不需要更改代码/数据库更简单的呢？
• 并非所有商品都应打折 - 例如退款、退货、订阅（如果适用）。它变得太复杂了，没有必要在数据库中表示折扣的业务逻辑。将计算等留在应用程序代码中，将结果存储在数据库中
• 拥有自己的项目意味着计算可以任意复杂。这意味着随着复杂性的增加无需维护数据库。维护/更改代码比维护/更改数据库要容易得多
• 最后，我成功搭建了一个发票系统，我采用了“item”的方式，效果非常好

Answer 2

这些选择中的任何一个都会对您产生什么后果？例如，您希望以后有多个折扣，还是非常具体的折扣？如果每张发票只有一个折扣，那么我不会让它变得比需要的更复杂。在我看来，将它放在发票表中会更容易、更清晰——我认为，将其作为负面项目会使项目的处理更加困难。

Answer 3

我完全同意让它尽可能简单，但要考虑的一件事是，是否有任何商品应免于折扣？在这种情况下，您需要在详细信息中添加一个 bool 字段来记住哪一行应该有折扣。