视图中可用CASE实现基于字段值的条件计算，但必须为确定性表达式，禁止变量、非确定函数及嵌套子查询，各分支数据类型需兼容，并注意NULL判断和数据库差异。
视图里用 CASE 做动态列计算，完全可行，但必须写成确定性表达式
SQL 视图不支持变量、参数或运行时输入，所谓“动态”实际是指基于已有字段值做条件分支计算。只要 CASE 表达式不依赖外部传参、不调用非确定性函数（如 NOW()、RAND()），就能安全用于视图定义。
常见错误是试图在 CASE 中引用不存在的列，或混用聚合与非聚合字段而没加 GROUP BY —— 这会导致视图创建失败或查询报错 ERROR 1055（尤其在 MySQL 5.7+ 严格模式下）。
-
CASE必须放在SELECT列表中，不能出现在WHERE或ORDER BY子句里再被视图“复用” - 所有分支返回的数据类型需兼容，否则隐式转换可能出错（例如一个分支返回
INT，另一个返回VARCHAR，MySQL 可能转成字符串但长度截断） - 避免在
CASE中嵌套子查询——视图定义虽允许，但每次查询都会执行，性能极差，且 PostgreSQL 等会直接拒绝
MySQL 和 PostgreSQL 中 CASE 写法差异很小，但 NULL 处理要特别注意
两者都支持简单 CASE column WHEN value THEN ... 和搜索型 CASE WHEN condition THEN ...，但对 NULL 的判断逻辑一致：不能用 = NULL，必须用 IS NULL。
例如想把空邮箱标记为 'no_email'，下面写法在两个数据库都有效：
SELECT name,
CASE
WHEN email IS NULL THEN 'no_email'
WHEN email LIKE '%@gmail.com' THEN 'gmail'
ELSE 'other'
END AS email_type
FROM users;- PostgreSQL 对数据类型推导更严格，若分支返回不同类型，需显式用
::text或CAST(... AS text)统一 - MySQL 8.0+ 支持
CASE作为窗口函数的一部分，但在视图中慎用——窗口函数要求OVER()，而很多 ORM 或 BI 工具解析视图列时无法识别其窗口属性 - 别在
CASE分支里写SELECT COUNT(*) FROM ...——这不是“动态”，这是反模式
当需要“按角色算不同折扣”这类业务逻辑时，CASE 是最轻量解法
比如订单表 orders 有 user_id、amount，用户表 users 有 role（'vip'/'normal'/'trial'），想在视图里直接带出折扣后金额：
CREATE VIEW order_with_discount AS
SELECT o.id,
o.amount,
u.role,
CASE u.role
WHEN 'vip' THEN o.amount * 0.8
WHEN 'normal' THEN o.amount * 0.95
WHEN 'trial' THEN o.amount * 1.0
ELSE o.amount
END AS discounted_amount
FROM orders o
JOIN users u ON o.user_id = u.id;- 这种写法比建额外计算列或触发器更透明，也比应用层 if-else 更易统一维护
- 如果
role字段可能为NULL，必须显式处理WHEN NULL分支（实际要用WHEN u.role IS NULL），否则该行discounted_amount会是NULL - 注意：视图不会自动更新索引，若后续常按
discounted_amount范围查询，得在基表字段上建索引，而不是指望视图列能走索引
别把视图当存储过程用，复杂逻辑该拆就拆
有人试图用多层嵌套 CASE 实现“根据地区+等级+下单时间”组合计算运费，结果语句长达 50 行、难以调试、修改一个条件就得重测全部分支。这已经超出 CASE 的合理使用边界。
- 超过 5 个分支或涉及日期计算（如“本月第几天”）、字符串解析（如从
sku_code提取分类）时，优先考虑用函数封装逻辑，再在视图里调用 - 如果业务规则频繁变更（比如折扣率每月调整），硬编码在
CASE里等于每次都要DROP/CREATE VIEW，不如建一张配置表，用LEFT JOIN替代CASE - 视图里的
CASE本质是查询时计算，不是预存结果——它不减少 I/O，也不加速聚合，只是让 SQL 更可读
真正容易被忽略的是：视图定义本身不校验字段是否存在，直到第一次 SELECT 才报错；所以改了基表结构后，务必手动查一次视图，不能只靠 DDL 语句成功就认为万事大吉。
