SQL DB 结构 - 订单草稿和订单 ID 作为标识符的考虑

Posted 2023-03-31

【中文标题】SQL DB 结构 - 订单草稿和订单 ID 作为标识符的考虑

【英文标题】：SQL DB structure - Draft orders and consideration of Order ID as identifier

【发布时间】：2018-07-10 13:19:40

【问题描述】：

我正在为大约 10 年前自己开发的客户升级系统。

这是一个标准的（当然，如果有的话）销售/库存/会计系统。

他们向我询问的新增功能之一是创建草稿订单的能力。随着公司的发展，订单的规模也在扩大。他们希望能够开始为客户输入订单，并可以选择保存并稍后再返回。

我最初的想法是创建一个包含草稿和表示状态（草稿/已发布）的字段的订单表。这将防止在 Orders 表和 DraftOrders 表中重复数据。

这对我来说似乎是正确的，但 OrderId 字段（自动增量 int）当然不再是订单的可靠标识符（因为订单之间的很多数字可能会丢失）。

理想情况下，客户希望将 OrderId 保留为标识符，那么是否有任何解决方案可以实现这一点，而不是创建草稿订单表？

非常感谢您的帮助。

亲切的问候

【问题讨论】：

没有理由假设主键没有间隙。你的解决方案很好。

亲爱的戈登，非常感谢您的回复。对于订单 ID 和发票 ID，确保它们在税收和报告方面的统一顺序通常很重要。我上面概述的方法会在订单 ID 中产生间隙。

你使用的是哪个数据库

亲爱的 Gaj，我正在使用 SQL Server。谢谢

【参考方案1】：

如果您要确保标识符没有用于税收目的的间隙，则首先不能使用 PK。这是因为序列也可能有间隙。例如，如果 INSERT 由于违反某些约束而失败，您将丢失保留的序列号。

如果您不想创建单独的表，我可能会建议添加一个新列来存储税单 ID。对于草稿，它将保持为 NULL，并在下订单时以编程方式填充。在 UI 上，您将显示这个新列，并可能允许在其上进行一些搜索（提示：索引的良好候选者），但在内部，您仍将使用与以前相同的 FK（对于订单和草稿）。

【讨论】：

亲爱的鲍里斯，感谢您的评论。经过深思熟虑，我相信您的解决方案是最好的方法。亲切的问候