编程与软件工程brandur.org
软删除可能不值得
Soft deletion probably isn't worth it
2022 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Brandur 的这篇文章讨论“软删除”（用 deleted_at 标记而非真正删除行）的实际代价：每个查询都要额外过滤、唯一索引和唯一约束会变得棘手、外键和级联语义变复杂、数据不断膨胀。他认为多数项目默认采用软删除并不划算，除非确有审计或合规留存需要，否则可以考虑硬删除加归档/审计日志等替代方案。
为什么经久不衰：这是每个做 CRUD 的团队都会撞上的经典工程权衡，文章把隐性成本讲得很具体，因此反复被拿来讨论。
HN 评论精选
默认上软删除+审计轨迹，前期成本远低于事后补，性能问题可用定期清理任务缓解。
我从 90 年代开始做开发，现在已经默认实现审计轨迹和软删除，除非有明确理由不这么做。总有人想恢复被删的东西、查为什么被删、看谁改了什么。这对业务有帮助，也给你调试信息，还能在真出数据丢失事故（其实是用户误操作）时保护你。软删除有明显缺点，但通常比在流程外做冗长日志省事得多；事后补加往往要多花一个数量级的功夫，可以上线前就加好但先关着。性能问题一般也能缓解，比如跑个每日清理任务把软删除超过 n 天的数据硬删掉。
JohnBooty查看英文原文
I've been a software dev since the 90s and at this point, I've learned to basically do things like audit trails and soft deletion by default, unless there's some reason not to. Somebody always wants to undelete something, or examine it to see why it was deleted, or see who changed something, or blah blah blah. It helps the business, it helps you as developer by giving you debug information as well as helping you to cover your ass when you are blamed for some data loss bug that was really user error. Soft deletion has obvious drawbacks but is usually far less work than implementing equivalent functionality out-of-stream, with verbose logging or some such. Retrofitting your app and adding soft deletion and audit trails after the fact is usually an order of magnitude more work. Can always add it pre-launch and leave it turned off. If performance is a concern, this is usually something that can be mitigated. You can e.g. have a reaper job that runs daily and hard-deletes everything that was soft-deleted more than n days ago, or whatever.
用带 deleted_at IS NULL 过滤的可更新视图，可以低成本地把软删除的复杂度藏起来。
视图是这个问题的简单解法。几乎所有现代关系型数据库都支持可更新视图，在表上建一个带 WHERE deleted_at IS NULL 的视图就能解决作者的大部分问题（如果删除方式得当，外键问题也包含在内）。我觉得很多开发者严重低估了自己所用数据库引擎的能力。担心逻辑分散在数据库层和应用层确有道理，但通过迁移、分区等手段保持两者一致的技术已经很成熟了。
dafelst查看英文原文
Views are a simple solution to this problem. Pretty much all moderns RDBMSs support updatable views, so creating views over your tables with a simple WHERE deleted_at IS NULL solves the majority of the author's problems, including (IIRC) foreign key issues, assuming the deletes are done appropriately. I feel like a lot of developers underutilize the capabilities of the massively advanced database engines they code against. Sure, concerns about splitting logic between the DB and app layers are valid, but there are fairly well developed techniques for keeping DB and app states, logic and schemas aligned via migrations and partitioning and whatnot.
合规留存与审计要求才是逻辑删除最主要、最有价值的动机。
“软删除的理念是让删除更安全、可撤销。”这只是一部分。另一部分是很多行业有监管的数据留存和审计要求，这可以说是有逻辑删除最有价值、最常见的原因。
giantg2查看英文原文
"The concept behind soft deletion is to make deletion safer, and reversible." That's one part. The other part is that in many industries you have regulatory data retention and audit requirements. This is arguably the most valuable and common reason to perform Logical deletes.
真实案例：脚本误删数万文件，靠服务商的软删除才恢复，说明必须验证软删除确实可用。
我上一家公司用程序调用 Box 存文件。有一天撞上了墨菲定律：一个脚本出错删光了所有文件（几万个），我们看不到任何恢复途径，简直是灾难。我们把 Box 的客服拉进电话说明情况，对方停顿了一下、点了几下鼠标，然后说：“好，这些文件一小时后会回到你们账户里。”这百分之百是我们的错，但那天软删除救了我们。如果你或你的客户可能遇到类似情况，不仅该采用软删除，还要确保它真的能用。
danielrhodes查看英文原文
In a previous place I worked, we were programmatically using Box to store files. One day we were presented with a case study in Murphy's Law: a script went awry and deleted everything (10s of thousands of files). There was no clear way to recover these files, they were gone from what we could see. It was a disaster. We got a Box support person on the phone and described what had happened. There was a pause, some mouse clicking and then: "Ok, those files will be back in your account in an hour." It was 100% our fault. But soft deletes saved us that day. If you're in a situation where you or your customers could benefit from the same, it's wise to not only embrace them but also make sure they work.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选