日历条目存储疑问：合并起止日期时间是否违反数据规范化？

数据规范化角度 #

合并存储start_datetime和end_datetime完全不违反数据规范化。日期与时间本质上是一个不可分割的时间点属性，拆分反而会引入冗余数据和一致性风险：

• 拆分后需要确保startDate与startTime、endDate与endTime始终匹配，一旦出现更新失误（比如只改日期不改时间），会导致数据错误。
• 时区处理时，单独的日期和时间字段无法准确映射到统一的时间戳，容易出现逻辑漏洞。

查询效率与前端处理 #

合并存储反而更利于查询效率：

• 单个datetime字段可以直接做范围查询（WHERE start_datetime BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59'），单字段索引的性能远优于startDate+startTime的联合索引。
• 前端加载时，返回单个datetime字段后，用JavaScript的Date对象即可轻松拆分出日期和时间部分，比处理四个独立字段更简洁，还能减少数据传输量。

业务场景的特殊情况 #

只有当你有非常明确且高频的单独查询需求（比如只按日期过滤、不关心具体时间，或只按时间段过滤、不关心日期），才需要考虑拆分，但这种情况更推荐的方案是：

• 保留合并的datetime字段作为主存储。
• 基于datetime字段创建函数索引（比如MySQL的INDEX idx_event_date (DATE(start_datetime))），既不破坏规范化，又能提升特定查询的效率。

最终建议 #

• 优先使用带时区支持的datetime类型（如PostgreSQL的timestamptz、MySQL的datetime(6)）存储start_datetime和end_datetime，这是行业通用的成熟方案。
• 避免拆分日期和时间字段，除非有不可替代的业务硬需求。

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