SQL CASE语句按出生日期匹配世代仅返回ELSE值问题排查

所有分支都走ELSE是语法错误+写法隐患共同导致的：

• 日期常量未加单引号，被SQL解析为算术运算表达式而非日期值：你写的01/01/1945这类内容没有用单引号包裹，SQL不会将其识别为日期，会直接按数学除法计算，比如01/01/1945等价于1/1/1945 ≈ 0.0005。而日期字段存储的本质是距离基准日期的时间戳数值（主流数据库中20世纪以来的日期对应时间戳都是远大于0的整数），拿日期字段和这些极小的计算值做区间比较，永远不会满足匹配条件。
• 比较运算符书写错误：最后一个世代的判断条件里，大于等于的正确写法是>=，你写的=>不符合SQL语法规范，部分容错性差的数据库甚至会直接抛出语法错误，不会执行匹配逻辑。
• 额外隐患：你用的dd/mm/yyyy日期格式兼容性极差，不同数据库的区域设置不同，很容易把日、月解析错位，比如01/05/1995可能被识别为1月5日，也可能被识别为5月1日，导致匹配结果错误。

CASE
WHEN [Date of Birth] BETWEEN '1945-01-01' AND '1964-12-31' THEN 'Baby Boomer'
WHEN [Date of Birth] BETWEEN '1965-01-01' AND '1981-12-31' THEN 'Gen X'
WHEN [Date of Birth] BETWEEN '1982-01-01' AND '1994-12-31' THEN 'Millenial / Gen Y'
WHEN [Date of Birth] BETWEEN '1995-01-01' AND '2010-12-31' THEN 'Gen Z'
WHEN [Date of Birth] >= '2011-01-01' THEN 'Gen Alpha'
ELSE 'Other TBC'
END

• 上述代码默认适配支持方括号转义标识符的数据库（如SQL Server、Access），如果在MySQL、PostgreSQL等环境运行，把字段名外的方括号替换为反引号或双引号即可。
• 修复中统一使用yyyy-mm-dd的ISO标准日期格式，不受数据库区域配置影响，不会出现日月解析错位的问题。

内容的提问来源于stack exchange，提问作者Lynne