Database 数据库最佳做法-现状

我正在创建一个应用程序，其中对象具有状态查找。为了提供一些上下文，让我们使用以下示例

---

帮助台应用程序，其中创建作业并通过以下工作流移动：

新建-已创建但未分配的作业
正在进行中-分配给工人并正在进行的工作
完成-作业完成准备开票
已关闭-已开具工作发票

---

因此，我创建了一个包含以下详细信息的状态表：

intID
字符串名称

以及作业表上的查找列

intID
字符串名称
int客户ID
intStatusID->查找状态

所以在现实世界中，假设我们有以下要求

用户需要获得一份报告来显示所有未完成的作业（新作业或正在进行的作业）

下线，有人想添加一个新的状态，例如处于完成和关闭的中间状态。

因此，考虑到这一点，我最初的想法是在状态表上创建一个名为SortOrder或类似的新列，并为其分配数字，如

新增-10
正在进行中-20
已完成-30
关闭-40

这意味着对于上面的案例1，我可以简单地查询数据库中状态大于或等于30的所有工作。这对于案例2也很好，因为这意味着如果我在完成和关闭之间引入一个新状态，它不会破坏此报告

---

我可以看到，它会经常出现在不同的应用程序中。以前有没有人实施过这样的解决方案或遇到过这样的问题？

我们所做的是有一个状态表和一个伴随状态组表

create table status_group (
    id integer primary key not null,
    alias varchar(20) not null,
    descr varchar(128)
)

create table status (
    id integer primary key not null,
    status_group_id integer,
    alias varchar(20) not null,
    descr varchar(128)
)

---

然后，所有状态都存在于一个点中，但被分组在一起，而不是拥有无数个单独的状态。

保留不推荐的数据（如关闭的作业）将开始使查询速度变慢，并引入逻辑，相当于必须不断跳过死记录。关闭不一定意味着不推荐。就帮助台系统而言，允许技术人员回顾客户的工作历史可以提供很多实际用途。随着系统多年来的成熟，数据库将保存大量不推荐的数据，无法安全迁移。在早期设计此迁移可以帮助系统优雅地老化。我从来没有说过要去掉数据，只是为了不把它保留在主表中，因为主表中的查询速度很重要。此外，您可能希望在代码中使用日期而不是值，这样您可以跟踪每个活动所用的时间。为代码添加一个额外的表可能会节省一些行，但这将增加功能。谢谢回答，我不太明白。在我的情况下，这将如何使用？