视图中硬编码时间过滤会丧失灵活性，应由应用层或查询层处理；推荐用行级安全（RLS）按角色动态控制可见时间范围，或通过参数化函数替代。
视图里用 WHERE 过滤历史数据会丢失查询灵活性
直接在视图定义中写 WHERE created_at >= '2024-01-01' 看似简单，但实际会让所有依赖该视图的业务逻辑被硬编码时间范围绑架。下游 SQL 无法再查历史数据，哪怕只是临时排查问题也不行。
更关键的是，这类过滤会让视图失去“虚拟表”的语义——它本该是原始表的逻辑投影，而不是一个带业务规则的快照。
- 视图应尽量保持与基表结构一致，仅做字段重命名、计算列、JOIN 整合等无损操作
- 时间过滤属于应用层或查询层职责，不是视图层该干的事
- 若真要“隐藏”，应通过权限控制（如行级安全策略）或使用物化视图+定时刷新，而非在 SQL 视图里硬切
用 DATE_TRUNC 实现动态时间截断（PostgreSQL / BigQuery）
DATE_TRUNC 本身不用于过滤，而是用于对时间字段做归一化处理，比如把 '2024-03-15 14:22:08' 截断成 '2024-03-15' 或 '2024-03-01'，方便后续按天/月聚合或关联。它常被误当成过滤手段，但真正起过滤作用的仍是 WHERE 或 HAVING。
如果你需要“只显示当月及之后的数据”，正确做法是在查询视图时加条件，而不是塞进视图定义：
SELECT * FROM orders_view WHERE DATE_TRUNC('month', order_time) >= DATE_TRUNC('month', NOW());-
DATE_TRUNC('month', order_time)返回当月第一天，比用order_time >= '2024-03-01'更可靠（避免时区/边界值问题） - MySQL 用户需改用
DATE_FORMAT(order_time, '%Y-%m-01')或LAST_DAY(order_time) + INTERVAL 1 DAY - INTERVAL 1 MONTH - SQL Server 用户对应的是
DATEFROMPARTS(YEAR(order_time), MONTH(order_time), 1)
用参数化视图替代硬编码（仅限支持的数据库）
PostgreSQL 不支持参数化视图，但可用 CREATE FUNCTION 模拟：
CREATE OR REPLACE FUNCTION recent_orders(since_month TEXT DEFAULT '2024-01') RETURNS TABLE(id INT, amount NUMERIC, order_time TIMESTAMP) AS $$ SELECT id, amount, order_time FROM orders WHERE order_time >= to_date(since_month || '-01', 'YYYY-MM-DD'); $$ LANGUAGE sql;
调用：SELECT * FROM recent_orders('2024-03');
- 这比修改视图定义更灵活，也避免了重复建多个“orders_view_2024q1”类视图
- 注意：函数返回类型必须显式声明，且不能在函数体内执行 DML
- SQLite、MySQL 均不支持此模式；Oracle 可用带参数的物化视图（但刷新机制复杂）
真正需要“隐藏”的场景，优先考虑行级安全（RLS）
如果目标是让不同角色看到不同时间范围的数据（如客服只能看近30天，审计可看全部），视图不是最佳载体。PostgreSQL 的 RLS 才是正解：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY; CREATE POLICY orders_recent_only ON orders FOR SELECT USING (order_time >= CURRENT_DATE - INTERVAL '30 days');
开启后，普通用户查 SELECT * FROM orders 自动带上该条件，而 superuser 或 disabled policy 的 session 不受影响。
- RLS 规则绑定到表，不依赖视图，所有访问路径（包括 JOIN、子查询）都受控
- MySQL 8.0+ 可用
CREATE SQL SECURITY DEFINER VIEW配合用户变量模拟，但不可靠（变量易被覆盖） - 最易被忽略的一点：RLS 默认对
INSERT/UPDATE/DELETE也生效，务必显式指定FOR SELECT避免误锁写入
