我正在开发一个交易系统，下面是我的问题的简化场景。
- 用户在系统中输入 JOBS。
- 用户首先输入一个状态为 DRAFT 的 JOBS（并且该 Job 被赋予一个草稿编号）
- 当用户提交 JOB 时，状态更改为 SUMBITTED（它被赋予一个实际数字）
- 最后，当 JOB 完成时，状态更改为 POSTED。
我正在考虑为其创建 3 个独立的相同“作业”表。当作业从草稿变为已提交时，我移动数据。这主要是出于性能原因。大多数查询将针对当前的 JOBS，这将确保它的表不会被所有发布的内容弄得乱七八糟。此外，这样的表划分将提供结构改进，因为我可以使用 JOB 编号作为主键。如果只有一个表，草稿编号将需要更改为实际编号。并且主键永远不应该改变。
现在，我的问题是——我的方法有意义吗？通常有单独的桌子吗？如果有人对此有经验并可以提供反馈，那就太好了。
根据我对类似事物的经验（计划的工作和任务表），所有内容都在一张表中。通常有一个
status列，但所有状态的作业都在同一个表中（有时会有一个索引status）。至于主键，为什么不直接使用顺序 ID？我已经看到它工作得很好。您还可以将草稿编号和实际工作编号作为组合键，除非有其他我不理解的要求。如果您认为这会提高性能，请确保在进行任何更改之前您有只能通过这种方式解决的可衡量问题。还要尝试证明此方法会带来实际必要的性能提升。
我同意@FrustratedWithFormsDesigner：这是你应该用一张桌子处理的事情。听起来在不同步骤中作业的属性没有根本差异，因此没有与实体相关的原因为什么你会有单独的表。
关于性能，如果您使用的是 postgresql 或 SQL Server，则可以使用过滤索引和状态过滤器。如果只有很小一部分作业处于活动状态，这将很有帮助。即使您使用的数据库产品没有过滤索引，常规索引也很可能就是您所需要的。
或者，您可以将较旧的作业发送到存档表，如果您需要它们，它们在那里可用，但不会减慢对当前数据的查询。但只有在出现实际性能问题时，我才会走那条路。