Sql e非常简单，因为它只是一个where子句来过滤它们或将它们留在其中。唯一需要确保的是，生成的任何报告或统计数据都会过滤掉已删除的记录

然后，对于您所说的想要捕获的额外信息，只需将这些额外信息放入单独的“审计”表中即可。在我们的例子中，我们已经使这个额外的表非常通用，它可以保存任何表的审计信息。。。请参见下面的工作原理

Event
EventId   EventName   ...   Deleted
1         Dinner            0
2         Supper            1
3         Lunch             0
4         Lunch             1

Audit
AuditId    EntityTypeId     EntityId    ActionTypeId    ActionDateTime   ... etc 
1          1 (Event)        2 (EventId) 1 (Deleted)     2/1/2010 12:00:00
1          1 (Event)        4 (EventId) 1 (Deleted)     3/1/2010 12:00:00

现在，如果您还有其他要捕获的实体（比如位置-其中位置是一个表），那么它将如下所示

Audit
AuditId    EntityTypeId     EntityId    ActionTypeId    ActionDateTime   ... etc 
1          1 (Event)        2 (EventId) 1 (Deleted)     1/1/2010 12:00:00
1          1 (Event)        4 (EventId) 1 (Deleted)     2/1/2010 12:00:00
1          2 (Event)        2 (LocationId) 1 (Deleted)     3/1/2010 12:00:00
1          2 (Event)        8 (LocationId) 1 (Deleted)     4/1/2010 12:00:00
1          2 (Event)        9 (LocationId) 1 (Deleted)     5/1/2010 12:00:00

然后，当你想获得额外的审计数据时，你所说的其实很简单。这个查询看起来像这样

SELECT  *
FROM    Event E
        INNER JOIN Audit A
            ON E.EventId = A.EntityId 
WHERE   E.Deleted = 1
        AND A.EntityTypeId = 1 -- Where 1 stands for events

此外，此审核表还可以捕获其他事件，而不仅仅是删除。。。这是通过使用ActionTypeId列完成的。目前它只有1个（即delete），但您也可以有其他的

希望这有帮助

编辑：

除此之外，如果我们有强烈的审计要求，我们将执行以下操作。。。上面没有任何更改，但我们创建了另一个名为“xyz_Audit”的数据库，该数据库捕获数据库中发生的每个操作的前置和后置。第二个数据库与第一个数据库具有相同的模式（没有审计表），只是每个表都有两个额外的列

第一个额外列是PrePostFlag，第二列是Audid。因此，主键现在跨越3列，“xyzId”、“PrePostFlag”和“audited”

通过这样做，我们可以赋予管理员充分的权力，让他们知道谁在何时做了什么，更改的数据以及它是如何更改的，要取消删除记录，我们只需要更改主数据库中的deleted标志

---

另外，通过将这些数据放在不同的数据库中，我们可以对主数据库进行不同的优化、存储和管理计划

这在很大程度上取决于表的大小以及您是否真的需要有关删除的附加信息

在大多数情况下，您只需要删除标志字段。然后创建一个视图，用于选择尚未删除记录的记录。将视图用于用户的所有查询，而不是直接访问表

如果您进行了审核，则您已经知道是谁将记录标记为已删除以及何时删除

如果没有，则应将这些字段添加到表中

我可能会定期将已删除的记录删除到存档表中，以提高主表上的查询性能。假设移动已删除超过6个月的所有已删除记录。然后创建一个视图，该视图结合了普通表和归档表，供管理员查询

---

这两种方法结合使用视图，可以让您充分利用这两个方面的优势，您的表在查询时非常小，每个人都可以看到他们需要查看的记录，并且可以相对轻松地取消删除意外删除的内容，存档旧记录可能发生在一天的低使用期，而不是记录被标记为删除时。

当用户创建、修改或删除事件时，请创建一个新的

事务

对象。在事务中存储有关事件更改的所有信息，并将其添加到表中，同时引用事件。这样，您就有了用户所做一切的审核日志。这增加了最小的复杂性，但也允许扩展。您甚至可以在以后添加撤消功能，对数据模型进行最小的更改（如果有的话）

---

因此，如果用户正在查看日志，您可以检索每个日志，而无需与之关联的删除事务，虽然管理员可以看到一切。

你可以考虑把这个标记为社区维基——我不确定你会找到一个可验证的正确答案。这是一个很好的问题，我期待看到一些答案出现。如果需要保留对事件表的任何引用以用于历史目的，则在复制到已删除的事件表时从表中删除行可能会导致一些问题。您将要么得到悬挂的外键，要么得到可能必须与这两个表联接的外键。这听起来不太好。为什么我的回答不再是答案？我是个新来的叠加者——我认为不止一个回答可以是答案。但我想可能不是。我完全同意这种方法。为什么是快照而不是事务？@calico:我假设事务是指存储更改的内容而不是状态？我相信这两种方法都适用于审计，但是快照方法允许您在任何给定时间轻松确定对象的状态-我们在许多项目中都有此要求。只是澄清一下：我将使用命令设计模式来实现事务。随着时间的推移，由于低值数据被无限期保留，此模式的查询速度将越来越慢。此外，这将要求在创建报告时检查标志，从而消除关注点分离的好处，并在不应该检查的地方包括基于记录的逻辑。一种更好的方法，而不是这种“软删除”方法，是使用数据库归档方法？为什么低价值的数据应该保存在高性能数据库中？@Travis。有趣的是，投了反对票。你能澄清你的评论吗？第一个我搞不懂。至于第二个，你认为OP的客户想要保留数据是错误的吗？因此，我试图帮助他是不好的，因为他一开始就不应该这样做？我应该告诉他，他的客户想要保留这些数据是错误的？你应该告诉他，在生产数据库中保留不推荐的数据是错误的。我同意，使用另一个数据库提供了许多明显的优势，例如不必在查询中云计算逻辑或