货运搬家小程序从0到1（二）：数据库设计，8 张表撑起核心业务

货运搬家小程序从0到1二数据库设计8 张表撑起核心业务上篇定了技术栈Spring Boot 3 单体 uni-app Vue3 管理后台。这篇落库表设计——表设计错了后面全部返工所以它值得单独一篇。本篇目标8 张表覆盖用户、司机、车型、订单、订单日志、钱包流水、评价、管理员。表用途user微信用户openid 唯一driver司机档案 审核状态 钱包余额vehicle_type车型与费率配置order_info订单主表order_log订单操作留痕wallet_flow每一笔钱的流水review用户对司机的评价admin_user后台管理员三个关键设计决策1. 状态字段用字符串不用数字枚举statusVARCHAR(20)-- UNPAID / PENDING / ACCEPTED / ...很多人爱用 tinyint 注释0待支付 1待接单。但三个月后你排查线上数据时WHERE status3和WHERE statusIN_PROGRESS谁更不会看错状态枚举值得那点存储空间。2. order_log 从第一天就要有CREATETABLEorder_log(idBIGINTPRIMARYKEYAUTO_INCREMENT,order_idBIGINTNOTNULL,actionVARCHAR(50),-- CREATE / PAY / GRAB / START / FINISH / CANCELdetailVARCHAR(500),created_timeDATETIME);每次状态流转插一条。它不是日志系统是客诉时的唯一真相“司机说他没收到取消通知”——订单日志一查时间线清清楚楚。3. wallet_flow 双向记账余额只是缓存钱包流水表记录每一笔支付PAY、司机收入INCOME、提现WITHDRAW。核心原则SUM(流水) 当前余额余额字段只是省得每次 SUM 的缓存。永远可以靠流水重算余额对账——这在出财务纠纷时是救命的设计。顺带说两个小规范金额一律DECIMAL(10,2)Java 侧一律BigDecimal。用 double 存钱的上线第一天就会遇到 0.10.2≠0.3所有表带created_time / updated_time别嫌烦排查这个数据什么时候变的全靠它本篇成果8 张表建完种子数据里放了 4 个车型小面包车 30 元含 5km、中面包 55、小货车 90、4.2 米厢货 160 含 8km和演示用户/司机。下一篇写计价引擎——这 4 个车型的费率是怎么配置进数据库、代码里一行都不用写死的。