餐厅在线预订系统ER图优化及MySQL VARCHAR长度最佳实践咨询

一、ER图与表结构优化方向 #

1. 冗余用户表结构优化 #

现有CUSTOMER和RESTAURANTOwner两张表存在大量重复字段（姓名、邮箱、用户名、密码、手机号），如果后续要做统一登录、权限管理会非常麻烦，建议：

• 可以抽象出通用USER基表存储公共字段，用user_type字段区分用户是顾客还是商家，减少冗余代码和维护成本
• 紧急优化项：当前密码字段设为VARCHAR(80)，绝对不能存储明文密码，加密后（推荐用bcrypt、Argon2等算法）建议将字段长度调整为VARCHAR(255)，兼容各类加密算法的输出长度，避免后续更换加密方案时改表结构

2. 餐厅表补充核心字段 #

现有RESTAURANT表仅保留了名称和布局字段，完全无法支撑业务使用，建议补充以下必要字段：

• 基础信息：餐厅地址、联系电话、营业时间、营业状态、人均消费、简介
• 原有RESTAURANT_LAYOUT字段用VARCHAR(255)存储完全不合理，布局信息建议改为JSON类型存储，或者单独关联SEAT_TABLE（桌位表），存储每个桌位的可容纳人数、位置、编号等信息

3. 预订表核心逻辑优化 #

现有RESERVATION表的设计存在较多业务缺陷：

• 联合主键过于冗余：当前用餐厅ID、顾客ID、预订日期、预订时间四个字段作为主键，后续修改预订、退订、关联其他业务数据都非常麻烦，建议新增独立的自增RESERVATION_ID作为主键
• 缺失核心业务字段：需要补充预订人数、预订状态（待确认、已确认、已完成、已取消、已爽约）、用户备注、商家备注、订单创建时间、最后更新时间
• 时间字段设计不合理：建议将分开的RESERVATION_TIME和RESERVATION_DATE合并为RESERVATION_START_TIME DATETIME类型，同时新增RESERVATION_END_TIME DATETIME字段，方便计算餐位占用时长，自动排查预订冲突

4. 补充缺失的业务表 #

如果要支撑正常运营，还需要补充以下必要的表结构：

• 桌位表：关联餐厅，存储每个桌位的编号、可容纳人数、位置等信息，预订记录需要关联具体桌位，避免同一桌被重复预订
• 支付表：如果支持预付订金、线上支付，需要单独存储支付记录
• 评价表：用户用餐后可对餐厅进行评价打分

二、MySQL VARCHAR字段长度设置最佳实践 #

针对你提到的长度规范不统一的问题，行业通用的设计原则如下：

1. 基础规则 #

MySQL 5.0.3之后VARCHAR类型最大支持65535字节的存储长度，属于变长存储，实际占用空间等于数据实际长度+1/2个字节的长度标识，不会因为设置的最大长度更大就浪费存储空间，只要不超过业务需要的合理范围即可。

2. 常见字段推荐长度 #

• 邮箱：根据邮箱协议标准，邮箱最长为320个字符，但实际业务中几乎不会出现超过200字符的邮箱，设置VARCHAR(255)完全可以覆盖所有场景，且支持直接加全字段唯一索引
• 用户名：建议设为VARCHAR(50)，过长的用户名会影响产品体验，也没有必要
• 手机号：建议设为VARCHAR(20)，支持带国际区号的手机号格式
• 真实姓名：建议设为VARCHAR(100)，覆盖少数民族、外文姓名的长度需求
• 加密后密码：建议设为VARCHAR(255)，兼容bcrypt、Argon2等各类主流加密算法的输出长度

3. 注意事项 #

如果字段需要建唯一索引，需要注意InnoDB引擎的索引长度限制：

• 未开启innodb_large_prefix的旧版本MySQL，单字段索引最大长度为767字节，用utf8mb4编码（4字节/字符）的话，VARCHAR(191)是可以建全字段索引的最大长度
• 新版本MySQL默认开启innodb_large_prefix，单字段索引最大长度为3072字节，常规业务场景下的字段长度都可以满足

内容的提问来源于stack exchange，提问作者Kil Gore