问在SQL表中引入"status“列会更改其定义。

EN

例如，当我需要向“人员”介绍“状态”时，我会删除"people“表，而是为”活着的人“和”死的人“创建变体。

您可以创建一个dead_people视图和一个living_people视图。无论如何，您的代码应该首先查询视图，而不是表。

我理解检查任何地方的开销，但是随着现代MVC方法和关注点的分离，查询某个表或视图的地方应该是非常有限的，而不是广泛存在的。您是否有可能在谈论遗留代码？去过那里，干过那事。创建视图，特别是为更广泛使用的案例创建视图会有所帮助。更有帮助的是创建函数或业务对象，这些函数或业务对象返回所需的内容，是查询数据库的唯一位置。

在表中使用“status”列是非常常见的，即使它可能会增加开销。另一个好处是，在这种情况下，您可以执行“逻辑或软”删除操作，因为您可以使用“status”列表示行数据的状态。

我(几乎)总是包含某种类型的“状态”或“标志”列，但这可能是由于我处理过的应用程序的类型所致。

我还遇到(但较少)每一行都有一个开始日期和结束日期，“活动”记录没有结束日期。但这只会帮助你处理“活动记录状态”。这里的好处是将历史记录保存在桌子上。一个明显的缺点是增加了空间消耗。

正如注释中提到的那样，您最好使用一个包含所有状态和相关代码的查找表。但是要小心，不要创建大规模的统一代码键(MUCK)表。

这使我得出这样的结论:这里没有一个灵丹妙药/一刀切的答案，因为“status”列的需求是由应用程序的需求驱动的。

将人们转移到dead_people很少有意义。它是归档清理的一种形式，因此原始表最优工作。一种用途是拥有一个快速的小用户表，用于大规模事件检查(用户权限)和一个包含完整信息的用户表。

对于O/R映射，当"status“列确定使用哪些其他列时，我建议使用判别器列，并使用数据库继承。这样，查询仍然可以维护。

假设你有一个关于人的问题，现在介绍死或活的人。然后，业务规则决定查询的范围:这段代码的目标是什么。

最明显的建议是不要重复自己。查询在某些标准中可能会有所不同。跟踪干燥的措施可以在JPA (java)中完成。

一个具体的例子：

数据记录器从设备接收二进制消息。这种消息由字节组成，包含多个信号、位组。对于此类二进制消息解析的定义，有一个表。信号是一个实体。

现在来了一个时刻，自定义的信号用户定义为信号的表达。信号变成消息指定的原始信号或基于表达式的自定义信号。现在考虑一下，自定义信号也可以从其他自定义信号中定义，而不仅仅是原始硬件信号。

这是一个语义更改信号= HardwareSignal xor CustomSignal。一个鉴别器列和单独的O/R映射就可以了。相应字段的干净分离:仅引用用于HardwareSignal的消息规范/信号规范。没有未使用的田地。因此，任何字段都不能非预期地访问。

对于一个好的软件维护来说，

就足够了.

所有这些都不是最优的，但我仍然没有遇到一个数据库+ O/R框架来优雅地做到这一点。尽管领域驱动开发和更多。但谁知道呢。