何时在数据库代码中实现软删除逻辑？答案

【问题标题】：When to implement soft delete logic in the code over the database?何时在数据库代码中实现软删除逻辑？
【发布时间】：2022-06-10 17:05:06
【问题描述】：

当我想将资源软删除作为我公司的一项政策时，我可以在两个地方之一进行。

我可以在我的数据库中使用一些“而不是 DELETE”触发器来执行此操作。像这样：

CREATE TRIGGER prevent_resource_delete
    BEFORE DELETE ON resource
    FOR EACH ROW EXECUTE PROCEDURE resource_soft_delete();

CREATE FUNCTION resource_soft_delete() RETURNS trigger
    LANGUAGE plpgsql AS
$$
BEGIN
    UPDATE resource SET deleted_at = now() WHERE id = OLD.id;
    RETURN NULL;
END;
$$;

几乎每篇关于软删除的文章都建议这样做。除了由 ORM 所有者专门撰写的文章，因为他们有自己的内部解决方案。

我喜欢这种方法。我的 API 中的逻辑看起来我只是在删除资源。

Resource.query().deleteById(id); // Using a query builder
db.query('DELETE FROM resource WHERE id = $1;', [id]); // Using native library

对我来说，这似乎更自然，我不必担心其他开发人员会意外硬删除内容。但对于那些不知道实际情况的人来说，这也可能会造成混淆。并且在数据库中有任何逻辑意味着我可以在那里有错误（软删除逻辑通常非常简单，但仍然......），这将很难调试。至少与我的 API 中的相比。

但我也可以在 API 本身中使用逻辑。将逻辑保持在其他逻辑旁边。不那么优雅但更直接。其他地方没有隐藏的逻辑。我确实失去了防止人们意外硬删除资源的保护。

Resource.query().query().findById(id).patch({deleted_at: new Date()}); // Using a query builder
db.query('UPDATE resource SET deleted_at = now() WHERE id = $1;', [id]); // Using native library

在考虑是否软删除数据库问题时，我倾向于选择前一个选项。数据库选择如何处理已删除的数据。删除的数据，无论是软的还是硬的，原则上不再是应用程序的一部分。 API 无法检索它。对于开发人员来说，它可以用于分析、法律原因或手动帮助想要恢复他/她认为丢失的东西的用户。

但我不喜欢缺点。我刚刚和一位担心的同事谈过，因为他认为我们实际上是在删除东西。现在，这实际上可以通过更好的入职和文档来解决。但应该是这样吗？

何时在代码中通过数据库实现软删除逻辑？为什么我找到的每一篇文章都直接建议数据库而不考虑代码？看来我找不到一个强有力的理由。

【问题讨论】：

标签： database soft-delete

【解决方案1】：

在我看来，没有任何强有力的理由，这取决于架构师和开发人员决定将逻辑放在哪里，但以下可能是其背后的可能原因::

首先，由于我们要从数据库中删除某些内容，因此将逻辑保持在最适合的位置，

第二次为每个 API 编写逻辑有点多余，而不是在 DB 中一次完成所有表、节点或集合的工作量较少。 :)

【讨论】：