POS 数据库 Schema 示例

以下 POS schema 示例展示了同样的门店-交易-支付核心如何适配单店小店、多店零售连锁、基于餐桌的餐厅 POS，以及没有固定收银台的移动 POS。

真实案例

使用场景: 构建首个零售 POS 的开发者

只有一行 Store；不需要到处带 store_id

Product (id, sku, name, price, quantity)

Sale (id, register_id, cashier_id, total, sold_at)

SaleItem (id, sale_id, product_id, quantity, line_total)

Payment (id, sale_id, method, amount)

这样组织的原因: 单店小店跳过门店维度——图表里数量直接放在 Product 上。Sale/SaleItem/Payment 的拆分仍必不可少，因为即使在单店行项和组合支付也很重要。

使用场景: 在一套 POS 上运营多个零售门店的团队

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

StoreInventory 保存每商品每门店的数量

Sale 引用 store_id 用于报表和对账

门店间调拨与销售分开追踪

这样组织的原因: 多店增加 Store 实体和按门店库存——图表现在需要 StoreInventory，因为同 SKU 在各门店数量不同，这与库存 schema 模式一致。

使用场景: 构建餐厅销售点的团队

Tables 和 Reservations 取代以 Customer 为中心

Sale（叫「Check」或「Bill」）关联到 table_id

SaleItem 引用 MenuItem 而非 Product

小费作为 Payment 上的独立字段追踪

挂账让一笔 Sale 跨多次到访保持开放

这样组织的原因: 餐厅 POS 把零售商品目录换成菜单，并把销售绑到餐桌——图表继承 Sale/SaleItem/Payment 核心，但加入零售不需要的桌面流程。

使用场景: 构建 Square 式移动收银的团队

Cashier 可从任意设备登录

Sale 捕获 device_id 和 gps_location

离线支持：联网恢复时同步销售

刷卡通过外接读卡器进行

这样组织的原因: 移动 POS 把收银台虚拟化——图表用设备会话取代固定终端，并加入离线同步，因为移动设备不能依赖持续联网。

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