WorkFine系统表设计中用的是这种方法，这里大胆猜测也安利下为什么这样设计。
感兴趣的可以阅读以下内容就明白为什么这样设计了
在 SQL Server（或其他关系型数据库）中，软删除（Soft Delete） 是一种常见的数据删除策略，它并不真正从物理上删除记录，而是通过添加一个标识字段（如 IsDeleted、DeletedAt 等）来标记该记录已被“逻辑删除”。应用程序在查询数据时会自动忽略这些被标记为已删除的记录。
一、软删除的基本设计
1. 表结构示例
CREATE TABLE Users (
Id INT IDENTITY(1,1) PRIMARY KEY,
Name NVARCHAR(100),
Email NVARCHAR(255),
IsDeleted BIT NOT NULL DEFAULT 0,
DeletedAt DATETIME2 NULL
);
IsDeleted = 1表示该记录已被软删除。DeletedAt可选，用于记录删除时间，便于审计或定期清理。
2. 查询时过滤软删除记录
SELECT * FROM Users WHERE IsDeleted = 0;
3. 软删除操作
UPDATE Users SET IsDeleted = 1, DeletedAt = GETDATE() WHERE Id = @UserId;
4. 恢复（可选）
UPDATE Users SET IsDeleted = 0, DeletedAt = NULL WHERE Id = @UserId;
二、优点
| 优点 | 说明 |
|---|---|
| 数据可恢复 | 软删除保留了原始数据，便于误删后恢复。 |
| 审计与合规 | 保留历史记录，满足 GDPR、SOX 等法规对数据追溯的要求。 |
| 避免级联问题 | 不会因外键约束导致级联删除复杂逻辑或意外数据丢失。 |
| 简化业务逻辑 | 某些业务场景（如用户注销但保留订单）天然适合软删除。 |
三、缺点
| 缺点 | 说明 |
|---|---|
| 性能下降 | 所有查询需额外过滤 IsDeleted = 0，若未建索引可能影响性能。 |
| 存储膨胀 | 长期积累大量“已删除”数据，占用磁盘空间。 |
| 索引效率降低 | 若索引未包含 IsDeleted 字段，可能导致执行计划不佳。 |
| 逻辑复杂度增加 | 开发者必须始终记得过滤软删除记录，否则易引入 bug。 |
| 唯一约束冲突 | 例如，用户删除后重新注册相同邮箱，若唯一索引未考虑 IsDeleted，会报错。解决方法：使用部分索引（Filtered Index）：CREATE UNIQUE INDEX UX_Users_Email ON Users (Email) WHERE IsDeleted = 0; |
四、最佳实践建议（SQL Server）
- 统一命名规范：所有表使用一致的软删除字段（如
IsDeleted,DeletedAt）。 - 创建视图：封装“有效数据”查询逻辑，避免重复写
WHERE IsDeleted = 0。CREATE VIEW vwActiveUsers AS SELECT Id, Name, Email FROM Users WHERE IsDeleted = 0; - 使用筛选索引（Filtered Index）：提升查询性能并支持唯一性约束。
- 定期归档或清理：通过后台任务将长期软删除的数据迁移到历史表或物理删除。
- ORM 支持：如 Entity Framework Core 可配置全局查询过滤器（Global Query Filter）自动处理软删除。
五、何时使用软删除？
✅ 适合场景：
- 需要数据恢复能力
- 法规要求保留操作日志
- 删除操作频繁但需保留上下文（如电商订单、用户评论）
❌ 不适合场景：
- 数据量极大且删除后无价值（如日志、临时缓存）
- 对查询性能极度敏感
- 存储成本是关键考量
总结
软删除是一种以空间换安全和灵活性的设计模式。在 SQL Server 中合理使用（配合索引、视图、归档策略），可以在保障数据完整性的同时兼顾业务需求。但务必权衡其带来的维护成本与性能影响。
© 版权声明
THE END
