如何在数据库中存储用户日程？预约系统数据模型优化问询

嘿，这个问题我做类似预约系统时也碰到过，你的初始思路其实能跑通，但确实可以通过调整存储逻辑来大幅减少冗余，我给你几个更简洁的实现方向：

方案一：用「范围+规则」存储可用块，动态计算时段 #

不用把每个20分钟的slot拆成单独记录，而是在available表中直接存储用户设置的整小时可用块范围，字段可以设计成：

• user_id（关联用户的外键）
• start_datetime（可用块的起始时间，比如2024-05-20 09:00:00）
• end_datetime（可用块的结束时间，比如2024-05-20 12:00:00）
• slot_duration（固定为20分钟，也可以做成常量写死在代码里）

预约时，reservation表只存储具体被预约的时段：

• user_id（被预约者ID）
• booker_id（预约者ID）
• slot_start（该20分钟时段的起始时间，比如2024-05-20 09:20:00）

核心逻辑 #

查询可用时段时，先从available表中取出用户的所有可用范围，然后通过代码或SQL生成该范围内所有20分钟的slot，再排除reservation表中已被预约的slot即可。

这个方案的好处是：

• 存储量直接减少2/3，用户设置N小时的可用块，只存1条记录而非3N条
• 扩展性强，如果以后需要调整slot时长（比如改成30分钟），不用修改历史数据，只需要调整生成逻辑

方案二：贴合「整小时块」需求的精简存储 #

既然你明确提到用户是设置不同日期的整小时可用块，可以针对性设计表结构：

available表字段：

• user_id（外键）
• available_date（可用的日期，比如2024-05-20）
• available_hour（可用的小时数，比如9代表当天9:00-10:00）

reservation表字段：

• user_id（被预约者ID）
• booker_id（预约者ID）
• reserve_date（预约日期）
• reserve_hour（预约的小时段）
• slot_index（0/1/2，分别对应该小时内的第1/2/3个20分钟时段）

核心逻辑 #

比如用户设置5月20日9点到11点可用，available表只需插入2条记录（日期2024-05-20，小时9和10）。查询可用时段时，先查available中用户的可用日期和小时，再对应检查reservation中该日期小时下的slot_index哪些已被占用，剩下的就是可预约的。

这个方案更贴合你的当前需求，实现起来更简单，存储冗余也能大幅降低。

关于你初始方案的补充 #

你的原始思路其实也有优势：查询可用时段时不用额外计算，直接查available表就能拿到结果，适合小体量的系统。但如果用户量、预约量上来，3倍的冗余记录会增加数据库存储压力和查询开销，这时候上面的优化方案就更合适。

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