餐厅数据库 Schema 示例

以下餐厅 schema 示例展示了同样的菜单-订单-餐桌核心如何适配堂食、外卖、多门店连锁和重预订的高端餐饮。

真实案例

使用场景: 构建首个餐厅点单系统的开发者

MenuItem (id, category_id, name, price, available)

Order (id, table_id, status, total, created_at)

OrderItem (id, order_id, menu_item_id, quantity, subtotal)

RestaurantTable (id, number, seats)

订单关联到餐桌；无需配送地址

这样组织的原因: 堂食是最清晰的起步 schema——订单属于一张餐桌，订单明细表解决订单与菜单项之间的多对多关系，这是最需要做对的核心关系。

使用场景: 构建在线点餐应用的团队

Order 增加 delivery_address、delivery_fee 和 courier_id

Customer (id, name, phone, address) 成为核心

无餐桌关联——订单绑定顾客而非餐桌

OrderStatus 枚举扩展到备餐中、配送中、已送达

可选 Courier 表用于配送分派

这样组织的原因: 外卖把订单的锚点从餐桌转移到顾客地址——图表去掉餐桌关系并加入配送字段，这正是堂食与店外 schema 的核心区别。

使用场景: 在一套系统上运营多个餐厅分店的团队

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

MenuItem 可通过 location_id 或连接表做到门店专属

订单和餐桌都引用一个门店

价格可按门店不同（价格放在菜单-门店连接表上）

报表按门店汇总订单

这样组织的原因: 连锁增加一个几乎被其他所有表引用的 Location 实体——设计决策是菜单和价格是全局还是按门店，价格不同时图表应用连接表明确表达。

使用场景: 餐桌预订与点单同等重要的团队

Reservation (id, customer_id, table_id, reserved_at, party_size, status)

一张餐桌在不同时间有多个预订

可用性查询检查 reserved_at 时间窗是否重叠

订单可选地关联到一个预订

无空桌时用 Waitlist 表

这样组织的原因: 重预订的餐厅把预订关系作为一等公民——图表强调餐桌-预订关联和重叠检查，因为防止重复预订是这里 schema 的主要职责。

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