我不是DBA，但我尊重数据库理论。是不是添加了像isDeleted和sequenceOrder这样糟糕的数据库实践的列？
答案 0 :(得分：13)
这取决于。如果需要稍后访问该元组（例如，计算已删除的内容，或进行某种类型的历史分析），则能够软删除元组（即，将其标记为已删除而不是实际删除它）是必不可少的。根据索引的结构，它还有一个可能的好处，即在软删除行时（通过触及较少的索引）导致较少的磁盘流量损失。缺点是应用程序负责管理软键删除外键。
如果为性能进行了软删除，则定期（例如，每晚，每周）任务可以在低流量时段内清除软删除的元组。
在某些情况下，对某些元组使用显式的“序列顺序”非常有用，尤其是当依赖于某些其他领域（例如，ID，应用程序开发人员受过培训而不信任）不可能或明智地订购需要出于商业原因以某种特定方式订购的东西时。
答案 1 :(得分：5)
IsDeleted列有两个目的。
隐藏用户的记录而不是删除记录，从而将记录保留在数据库中供以后使用。
提供两阶段删除流程，其中一个用户标记要删除的记录，另一个用户确认。
不确定SequenceOrder是什么。你有特定的应用程序吗？
答案 2 :(得分：3)
绝对不是。每个数据库都有不同的要求，根据这些要求，您可能需要这些列。
isDeleted的一个示例可能是您希望允许用户界面删除不需要的东西，但是将它们保留在数据库中以用于审计或报告。或者，如果您拥有非常大的数据集，则删除操作非常慢，可能无法实时执行。在这种情况下，您可以将其标记为已删除，并定期运行批量清理。
sequenceOrder的一个示例是在UI中启用数据库行的任意排序，而不依赖于内部数据库顺序或后续插入。如果按顺序插入行，通常可以使它们无序。直到人们开始删除并插入新行。
答案 3 :(得分：2)
SequenceOrder听起来不太好（虽然你根本没有给出任何背景），但是我在职业生涯中使用了像IsDeleted这样的列进行软删除。
答案 4 :(得分：2)
既然你明确表示你对理论观点感兴趣，那么这就是：
在LOGICAL设计的层面上，在表格中有一个布尔属性几乎是一个坏主意（顺便说一句，理论的正确用语是“relvar”，而不是“table”）。原因是具有布尔属性使得定义/记录relvar在您的系统中具有的意义（关系理论将其命名为“Predicate”）非常尴尬。如果你包含boolean属性，那么定义这样一个relvar的含义的谓词必须包含一些构造，比如“......这里的-BOOLEANATTRIBUTENAME-这个元组已被删除了。”。这是一个尴尬的迂回曲折。
在逻辑设计级别，您应该有两个不同的表，一个用于未删除的行，另一个用于已删除的行 - 有人可能仍然感兴趣。
在物理设计层面，情况可能会有所不同。如果你有很多删除和删除，或者甚至只是很多删除活动，那么实际上有两个不同的表可能是一个坏主意。一个具有布尔属性的表充当两个逻辑表之间的“区别键”可能确实更好。如果是otoh，你有很多只需要未删除的查询活动，并且与未删除的查询活动相比，删除的那些活动量通常很大，那么最好还是将它们分开（并咬一口）关于你可能会得到更糟糕的更新性能的子弹 - 如果这是显而易见的。）
但是你说你对理论观点很感兴趣，理论（就我所知而言）实际上很少谈论物理设计的问题。
在sequenceOrder列中，这实际上取决于具体情况。我想在大多数情况下，您不需要它们，因为业务所需的项目排序最有可能是“有意义”的数据。但我可以想象sequenceOrder列被用来模仿插入时间戳等。
答案 5 :(得分：1)
支持别人所说的话，两者都可以取而代之。
在我们的CRM系统中，我在客户表中有一个isDeleted-like字段，这样我们就可以隐藏我们不再服务的客户，同时将所有相关信息留在数据库中。我们可以轻松恢复已删除的客户，并且我们可以严格执行参照完整性。否则，当您删除客户但又不想删除您为其完成的工作的所有记录时会发生什么？你是否留下客户悬挂的参考资料？
SequenceOrder再次允许用户定义的排序。我不认为我在任何地方都使用它，但是假设你必须按顺序列出你最喜欢的五种食物。按照需要完成的顺序完成五项任务。等
答案 6 :(得分：1)
其他人已经充分解决了isDeleted。
关于sequenceOrder，业务规则经常要求列表的顺序可能不是由实际数据确定的。
考虑优先级状态表。您可能有高，低和中等行。订购说明将为您提供高，低，中或中，低，高。
显然，该命令不会提供有关三条记录之间存在的关系的信息。相反，你需要一个sequenceOrder字段，这样才有意义。这样你最终得到[1]高，[2]中等，[3]低;或者相反。
这不仅有助于人类的可读性，而且系统流程现在可以为每个人提供适当的权重。