【问题标题】:Invoice tables Design发票表设计
【发布时间】:2011-09-11 17:48:38
【问题描述】:

我想知道如何设计发票表。

一张发票包括来自order 表的许多 个订单。

此发票表的设计是否正确?

订购

  • order_id (PK)
  • User_id (FK)
  • total_cost
  • 订单日期
  • 状态

order_item

  • order_item_id (PK)
  • order_id (FK)
  • item_name
  • 费用

发票表

  • invoice_id (PK)
  • invoice_no
  • 发票日期
  • period_start_date
  • period_end_date
  • 状态

invoice_order(包含许多订单的发票)

  • invoice_order_id (PK)
  • invoice_id (FK)
  • order_id (FK)

invoice_order 表是必须的吗?

我可以在 order_table 中添加 invoice_id (FK) 字段。当我在发票表中添加一行时,“order.invoice_id”将被更新。

【问题讨论】:

  • 最近几天我看到太多invoice design问题...
  • @ypercube,如果那些该死的教师代表他们所有的学生发布一次问题,这将节省时间。
  • 构建这样一个用于现实世界的系统几乎没有意义。我猜你的目的纯粹是为了教育。在这种情况下,我建议您决定要实现的目标,并为您的假设系统提出更好的规范。
  • @dportas 你是说设计不适合现实世界使用吗?我的问题是如何设计发票表格可以链接到一个或多个订单。

标签: mysql sql database database-design


【解决方案1】:

您只需要invoice_order 表,如果:

  • 一个订单可以有一张或多张发票

  • 发票可以链接到一个或多个订单

根据您在问题末尾的建议,情况就是这样。您不应该只拥有invoice_id 并在收到新发票时更新它,因为您会丢失订单和之前发票之间的链接。

更新

顺便说一句,你有costitem_name 的订单项很好,这对初学者来说很奇怪。由于历史原因,您必须拥有这些,并且可以使用相同的数据重新打印订单,例如,3 年后,当商品的名称可能略有更改并且成本肯定已经更新时。

【讨论】:

  • 谢谢阿德里安,你建议我应该怎么做?一张发票可以有很多订单,但是.. 发票不能有很多相同的订单。 (我问题末尾的建议不是很好的解决方案?)
  • 这是否意味着一个订单只能链接到一张发票​​?如果是这样,你为什么提到 order.invoice_id 更新?
  • 对不起,我的意思是发票可以是一个或多个订单。那么有 invoice_order 表好不好?
  • 如果一个订单可以有一张或多张发票,并且一张发票可以链接到一张或多张订单,那么是的,它是
【解决方案2】:

您需要链接表。一个订单可以包含多张发票(如果他们没有付款!),一张发票可以包含许多订单。在链接表中,虽然我不会打扰 •invoice_order_id (PK)。 PK 是两个 FK 字段的组合。这保证了唯一性,并且由于您不太可能拥有链接表的子表,因此通过向其添加代理键实际上什么也得不到。即使你做了两个索引 int 字段之间的性能差异,副一个也可能可以忽略不计。

【讨论】:

    【解决方案3】:

    大多数发票将包含:

    • 客户 ID
    • 销售代表 ID
    • 付款方式
    • 收货地址
    • 帐单地址
    • CheckBox:发货方式与计费方式相同

    【讨论】:

    • 好的。您的问题:此发票表是否设计正确?我的回答:没有。
    【解决方案4】:

    概括!!您应该考虑将其减少到 2 个表:Documents 和 DocDetails。只需在 Documents 表中添加一个 DocType 字段,以区分 Orders 和 Invoices。
    如果您需要跟踪延期交货,请将链接字段添加到您的 DocDetails。
    添加订单明细行时,为链接字段提供表 PK(计数器)的值。
    添加发票明细行时,为链接指定与相关订单明细相同的值。

    顺便说一句,在您的表格中没有看到任何 CustomerId !

    【讨论】:

    • 那将是性能最差的解决方案。在数据库设计中,泛化通常是一个非常糟糕的主意。
    • @hlgem:这是你的意见。我已经使用这个方案成功实现了,我知道我的建议是完美的。
    • @HLGEM:“概括通常是一个非常糟糕的主意”......你的句子确实是一个糟糕的概括。
    • @Idevelop,我说泛化在数据库设计中是一个糟糕的想法,并不是说它总是一个糟糕的想法。仅仅因为你做了一个糟糕的设计工作并不意味着如果你设计得好它就不会工作得更好。也许您应该对您使用的数据库的内部进行一些研究,看看为什么泛化不是最佳的。
    • 几个行业领先的 ERP 和会计系统确实使用具有通用文档编号和发票、贷项、付款、日记帐等通用列的通用表。如果您的财务文档具有共同属性,则根据根据正交设计原则,您应该为它们提供一个单独的表,或者具有约束以确保相同的元组不能出现在多个位置。
    猜你喜欢
    • 2012-01-29
    • 2014-02-11
    • 2011-02-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多