一对一预约
使用场景: 构建医生/教练/咨询师预订应用的团队
Service = 预约类型（咨询、复诊）
Resource = 从业者
Slot = 从业者日历上的 30 分钟窗口
Booking 关联客户 + 时段 + 服务
状态流转：待确认 → 已确认 → 完成/未到
这样组织的原因: 一对一预约是最清晰的预订场景——每个时段一个从业者、每个预订一个客户。图表的时段容量实际上是 1，使防重复预订成为简单的唯一约束。
真实案例
团体课程 / 活动
使用场景: 构建健身课或工作坊预订的团队
Slot 容量 > 1（如瑜伽课 15 个名额）
多个 Booking 可挂在一个 Slot 上
Slot 满员时用候补表
取消政策释放容量
每节课的导师存储在 Slot 上
这样组织的原因: 团体课程把时段容量提升到 1 以上——图表允许一个时段挂多个预订并加入候补，因为预订系统的主要工作变成管理容量而非防止并发占位。
设备 / 房产租赁
使用场景: 构建工具、汽车或度假租赁产品的团队
Resource = 可租赁物（汽车、房间、工具）
Booking 跨日期区间，而非单个时段
可用性查询检查重叠的日期区间
在 Booking 上追踪取还状态
定金 + 尾款分两条 Payment 记录
这样组织的原因: 租赁用日期区间取代固定时段——图表去掉 TimeSlot，在 Booking 上用 start/end 日期，可用性检查变成与已有预订的重叠查询。
多资源预订
使用场景: 一次预订同时占用多个资源的团队
BookingResource 连接表把一个预订关联到多个资源
例如：会议室 + 投影仪 + 餐饮
所有关联资源必须在同一时段空闲
可用性是资源日历的交集
取消释放每个关联资源
这样组织的原因: 多资源预订加入连接表，让一个预订同时占用多个资源——图表把可用性变成交集问题，这正是单个预订跨房间、设备和人时正确的形态。
使用技巧
- 把 TimeSlot 做成真实的表——每次请求都临时查询时间区间比索引化的 slot 行更慢、更难推理。
- 把 Service（被预订的）与 Resource（被使用的）分离——服务是产品，资源是约束。
- 给 Booking 和 Slot 独立的状态；Slot 可以在 Booking 「确认」前先「占位」。
- 多资源预订用连接表；千万不要按资源复制预订行。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=booking-system-database-schema
编辑此预订 schema 模板