视图本身不存储数据，无法实现版本控制；必须依赖SCD Type 2等带时间维度的基表结构，再通过参数化视图（如BETWEEN start_date AND end_date）查询指定时间点的有效数据。
视图本身不存储数据，无法直接实现版本控制
SQL 视图是查询的封装，不保存实际数据，也不自动记录变更历史。想靠 CREATE VIEW 本身实现“版本控制”或“历史快照”，行不通——它只是实时执行底层查询，每次查到的都是当前最新数据。
真正可行的路径是：先用表结构支持历史记录（比如带 valid_from、valid_to、is_current 的宽表，或用时间戳+事务ID的审计表），再用视图封装查询逻辑，让历史查询更简洁、安全、一致。
用 SCD Type 2 表 + 视图查“某时间点的有效版本”
常见场景：查用户在 '2024-06-15' 当天生效的姓名和邮箱。前提是底层表已按缓慢变化维（SCD Type 2）建模，含 start_date、end_date（end_date 为 '9999-12-31' 表示当前有效）。
- 视图定义中必须用
BETWEEN start_date AND end_date（注意闭区间），不能只写start_date ?，否则会漏掉end_date = '9999-12-31'的记录 - 参数化时间点建议用
DATE类型传入，避免字符串隐式转换导致索引失效 - 示例视图：
CREATE VIEW user_as_of AS SELECT user_id, name, email, start_date, end_date FROM user_history WHERE ? BETWEEN start_date AND end_date;
调用时：SELECT * FROM user_as_of WHERE ? = '2024-06-15';（具体语法依数据库而异，PostgreSQL/Oracle 支持参数占位，MySQL 需用存储过程或应用层拼接）
用 UNION ALL 视图合并“当前+历史”并标记版本来源
当历史数据分散在多个表（如 users_current 和 users_history），又不想改应用代码，可用视图统一出口，并加字段区分状态。
- 务必用
UNION ALL而非UNION，避免去重开销；两表结构必须严格一致（列名、类型、顺序） - 添加
version_type字段（如'current'/'archived'）比靠end_date判断更直观，也规避了 NULL 处理歧义 - 如果
users_history表没有updated_at，就无法排序出“最新历史版本”，视图里加ORDER BY updated_at DESC LIMIT 1会报错——视图不能含 LIMIT
视图性能陷阱：别在视图里嵌套复杂 JOIN 或子查询
历史查询常涉及多表关联（如订单→用户→地址→城市），若把这些全塞进视图定义，每次调用都强制执行完整链路，极易拖慢响应。尤其当底层表没建对 start_date/end_date 的联合索引时，BETWEEN 查询可能全表扫描。
- 优先让视图只做“裁剪+标注”，把聚合、JOIN 留给上层查询按需发起
- PostgreSQL 中可考虑用
MATERIALIZED VIEW缓存结果，但需手动REFRESH，且不支持自动增量更新 - SQL Server 的
INDEXED VIEW能提升性能，但限制极多（如不允许外联、不允许GETDATE()）
真正难的不是写视图，而是设计好带时间维度的基表结构——没这个基础，视图再漂亮也只是镜花水月。
