不够。视图硬写WHERE is_deleted = 0会强制过滤，无法支持回收站、审计等需查已删数据的场景；表结构变更时视图静默失效；应建v_table和v_table_active双视图，并在ORM层统一拦截且保留绕过接口。
视图里加 WHERE is_deleted = 0 就够了吗？
不够。直接在视图定义中硬写 WHERE is_deleted = 0 确实能过滤掉已标记删除的行，但问题在于：所有依赖该视图的业务逻辑都会被强制套上这层过滤，包括那些**本就需要查已删除数据**的场景（比如回收站、审计日志、软删恢复）。更麻烦的是，一旦表结构变更（比如字段重命名、is_deleted 改成 deleted_at），视图不会报错，只会静默返回空或错误结果。
CREATE VIEW 时用参数化逻辑？SQL 标准不支持
PostgreSQL 有 CREATE FUNCTION + RETURNS TABLE 可模拟参数化视图，MySQL 和 SQL Server 则不行。常见做法是退而求其次：建两个视图——一个带过滤（如 v_users_active），一个不带（如 v_users_all）。但这就要求开发人员**始终记得选对视图名**，漏掉一个地方就可能暴露已删数据或引发业务异常。
- 别把过滤逻辑塞进基础视图，它应该只是“原始数据快照”
- 用命名明确区分用途：
v_orders（含is_deleted字段） +v_orders_active（过滤后） - 在数据库文档或注释里强调：
v_orders是事实表映射，is_deleted字段必须由应用层显式处理
触发器 or 应用层统一拦截？选后者更可控
有人想用 INSTEAD OF 触发器在查询视图时动态改写 SQL，但这是危险操作：不同数据库对触发器的支持差异大（SQL Server 支持，MySQL 不支持），且无法覆盖 JOIN、子查询等复杂场景。真正靠谱的做法是：**在 ORM 或 DAO 层统一注入过滤条件**。
- 例如 MyBatis 的
@SelectProvider方法可默认追加AND is_deleted = 0 - Django ORM 用
Manager自定义get_queryset()，让User.objects.all()默认排除已删记录 - 关键点：保留一个绕过过滤的接口，比如
User.all_objects.all()或raw_query()
为什么不能依赖视图自动过滤全局行为
因为“全局自动”在 SQL 层面本质是幻觉。视图只是查询封装，不是访问控制策略。真正的软删除安全边界在应用层——你无法阻止 DBA 直连执行 SELECT * FROM users，也无法阻止另一个服务用不同连接池绕过你的视图。所以重点不是让视图“替你过滤”，而是让所有业务代码**默认走安全路径，且显式越界需付出认知成本**。
最易被忽略的一点：时间范围类查询（如“近7天订单”）如果只依赖 is_deleted = 0，会漏掉那些刚软删但时间仍在窗口内的数据。这时候过滤逻辑必须同时检查状态和时间字段，而这种组合条件，视图根本没法“全局自动”适配。
