完整出生日期包含年份，生日筛选只比较每年循环的月和日。本文解析 month_day 的归一化、跨年拆分与 SQL 生成链路。一次性分析可用项目级 SQL；同一口径需长期复用时，独立语义类型更便于集中治理，结果仍取决于数据质量和字段映射。
1. 同一个日期字段，业务含义可能不同
生日营销首先要筛出活动期内过生日的会员。在这个任务中，出生日期只用于判断月和日是否落在活动范围内。
计算年龄时，同一个字段需要保留完整的年、月、日。业务任务发生变化，日期参与计算的部分也会变化。
如果系统把年份带入生日筛选条件，SQL 依然可以正常执行，查询结果却可能偏离业务口径。因此，建模时需要明确区分完整日期与每年循环的月日。
2. 周期日期查询的三种实现路线
这类需求通常可以采用三种处理方式。选择主要取决于查询频率、应用范围和口径维护要求。
| 处理方式 | 合适场景 | 长期使用需要关注的问题 |
|---|---|---|
| 项目级 SQL 或计算字段 | 一次性分析、单个项目 | 规则复制后容易分散，数据库函数需要分别适配 |
| 提示词或动态 SQL | 快速验证新的问法 | 日期规则在查询时生成，一致性更依赖模型输出 |
| 独立语义类型 | 长期、反复使用的业务查询 | 前期需要完成字段映射，后续规则可以集中测试和修改 |
项目级 SQL 或计算字段
在单个项目中，可以直接编写日期转换规则。例如，在 ClickHouse 中使用 formatDateTime 提取月和日。这种实现路径清楚，适合快速满足当前查询需求。
当同一逻辑进入更多项目，日期函数、格式和边界处理可能随项目而变化。规则分散后，每次调整都需要逐项检查，长期保持统一口径的成本会随之增加。
提示词或动态 SQL
提示词或动态 SQL 适合快速验证新问法。月份、季度和日期区间的处理逻辑在查询时生成，规则一致性更依赖每次模型输出。
独立语义类型
长期、反复出现的周期日期查询，可以把“只比较月日”定义为公共语义规则。字段完成准备和映射后，月份、自然季度、单日和跨年区间会进入同一套处理链路。
3. month_day 如何定义
month_day 表示每年循环的公历月日，不保留年份。它的物理类型为字符串，统一规范为可比较的 MM-DD 格式。
在 Schema 中，最小的语义标记可以写成：
{
"name": "生日",
"type": "month_day"
}
规范化阶段可以处理以下典型输入：
| 输入 | 处理结果 |
|---|---|
7-3 | 规范为 07-03 |
1990-07-23 | 去掉年份，规范为 07-23 |
2-30 | 判定为无效日期 |
字段被标记为 month_day 后，系统在处理相关查询时只比较月和日。完整日期作为该属性的输入时，规范化规则会去掉年份和时间，只保留 MM-DD。
语义标记只定义字段含义，物理数据仍需单独映射。存量数据库通常需要映射已有月日列、视图列或预先生成的字段；类型声明本身不会自动派生新的物理列。
这项定义把原先隐含在项目代码中的处理逻辑，转化成数据模型中可见、可统一执行的规则。
4. 从自然语言到 SQL 的处理链路
周期日期查询可以按照以下顺序执行：
自然语言问题
→ 识别业务字段和时间表达
→ 生成 Logicform（逻辑形式），固定查询对象与条件
→ 将月份或季度转换为日期范围
→ month_day 去掉年份和时间，统一为 MM-DD
→ 将跨年范围拆成两个区间
→ 生成 SQL 并交给数据库执行
其中有两个关键处理环节。
月份和季度归一化
用户问“五月份过生日”时，系统先把“五月份”转换为明确的月日范围：
05-01 至 05-31
自然季度也会先转换为对应的起止日期，再进入 month_day 处理。
跨年范围拆分
统一为 MM-DD 后，跨年查询需要拆成两个连续区间。
例如，查询“12 月 28 日到 1 月 3 日过生日的人”，系统会生成：
12-28 至 12-31
或
01-01 至 01-03
对应的条件可以表达为：
(month_day >= '12-28' AND month_day <= '12-31')
OR
(month_day >= '01-01' AND month_day <= '01-03')
拆分后，每个条件都处于一个连续的月日区间内，可以继续进入通用的查询生成流程。
5. 准确性取决于完整的工程链路
独立语义类型的首要价值，是让相同的查询意图始终按照确定规则执行。
查询结果准确对应既定业务口径，需要同时满足以下条件：
- 源数据已经完成必要的数据检查。
- 业务字段正确映射为
month_day。 - 用户问题被正确识别为相应的月日条件。
- 查询属于当前支持的月份、自然季度、单日或跨年区间。
- 当前数据库环境已经完成适配和验证。
这些条件成立后，同一种 Logicform 会进入同一套日期归一化和查询重写规则，避免项目之间出现不同的月日处理方式。
规则集中也提高了查询过程的可检查性。数据团队可以确认字段使用了什么语义类型、日期范围如何转换、最终生成了什么查询条件。出现问题时，定位范围会更加明确。
6. 规则复用仍然需要字段映射
独立语义类型集中复用的是三部分能力：
month_day的语义定义- 日期归一化规则
- 查询重写规则
每个新的业务模型仍需完成字段标记、物理映射和数据质量检查。完成后，公共规则可以沿用；具体路线可按查询频率、应用范围和维护周期选择。
7. month_day 的工程边界
month_day 处理每年循环、只关心月和日的公历日期。目前适用的查询范围包括：
- 自然月份
- 自然季度
- 单日
- 跨年区间
以下情况具有单独的业务口径，需要另外定义：
- 农历生日
- 财务季度
- 时区换日
进入新的数据库环境时，仍需确认条件编码、SQL 方言和执行结果。独立语义类型可以降低业务规则对某一种日期函数的依赖，数据库执行层仍需结合实际环境处理。
8. 结论
周期日期查询的难点来自业务语义。同一个完整日期字段，在年龄计算中需要年、月、日，在生日筛选中只需要月和日。
将这层差异定义为 month_day，可以让月份、自然季度、单日和跨年区间沿着同一条处理链路执行。源数据、字段映射、意图识别、支持范围和数据库适配全部正确时，查询结果才能准确对应既定业务口径。
当这类查询只出现一次，项目级 SQL 足以完成任务。当规则需要长期维护并在多个项目中保持一致，独立语义类型提供了更清楚的工程边界。
FAQ
1. month_day 与普通日期字段有什么区别？
普通日期保留完整的年、月、日。month_day 只表示一年中的某个月和某一天，最终统一为 MM-DD，适合处理每年循环的公历日期查询。
2. 生日查询可以直接使用 SQL 日期函数吗？
可以。项目级 SQL 或计算字段适合一次性分析和单个项目。随着相同规则进入更多项目，日期函数、格式和边界处理可能逐渐分散，需要分别维护。
3. 为什么跨年查询需要拆成两个区间？
month_day 使用 MM-DD 表示月日。跨年范围覆盖年末和年初两个连续区间，因此需要分别生成 12 月末 和 1 月初的查询条件。
4. 字段标记为 month_day 后，查询结果会自动准确吗？
准确结果依赖完整的处理链路，包括源数据质量、字段映射、意图识别、支持范围和数据库适配。字段标记解决了月日语义的统一执行问题，其余环节仍需完成检查和验证。
5. 哪些时间问题需要单独建模？
农历日期、财务季度和时区换日具有各自的业务口径，需要单独定义。年龄计算等依赖年份的任务仍应使用完整日期。
