酒店管理数据库设计示例

以下酒店 schema 示例展示了同样的房间-预订-支付核心如何从单店扩展到连锁、与预订渠道集成，以及处理度假村式的增值服务。

真实案例

使用场景: 构建首个酒店预订系统的开发者

RoomType (id, name, base_rate, capacity)

Room (id, room_type_id, number, floor, status)

Booking (id, guest_id, room_id, check_in, check_out, status)

Guest (id, name, email, phone)

可用性查询：日期区间内无重叠预订的房间

这样组织的原因: 单店 schema 的关键决策是把 RoomType 与 Room 分离——房价和容量放在房型上，具体房间承载自己的房号和状态，从而让定价和库存清晰分开。

使用场景: 在一个平台上运营多家酒店的团队

顶部添加 Property (id, name, address)

RoomType 和 Room 都引用一个门店

预订按门店划分以便报表

即便同名房型，房价也可按门店不同

跨门店共享的中央客人档案

这样组织的原因: 连锁增加房间和房型所属的 Property 实体——设计选择是客人档案集中共享还是按门店，共享档案可实现跨门店的会员和历史记录。

使用场景: 与 Booking.com、Expedia 等同步的团队

Channel (id, name) 和每渠道的 RatePlan

Booking 增加 channel_id 和 external_ref

每渠道的库存配额以防超订

跨渠道追踪价格一致性

用同步日志表对账外部预订

这样组织的原因: 渠道管理增加每个预订的来源和按渠道的价格方案——图表的新职责是防止多个 OTA 销售同一批实体房间时超订，由配额关系建模。

使用场景: 增值收入与房晚同等重要的团队

Service (id, name, price) 增值项目录

BookingService 连接表把预订关联到服务，含数量

Folio（账单）按预订汇总房费 + 服务费

支付可针对账单总额部分支付

服务使用记录带时间戳以便计费

这样组织的原因: 度假村把服务作为一等收入——图表增加一个汇总房费和服务费的账单（Folio），于是单个预订累积一份滚动账单，而不只是固定房价。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。