前两天和同事改一个老模块的接口，查着查着发现数据库里居然有三个表存的是差不多的数据，字段命名还不统一，有的用下划线，有的用驼峰，时间格式也五花八门。一问才知道，当初建模时没人认真评审，各自为战，现在对接起来头疼得不行。
字段定义是否清晰合理
最怕看到叫 user_info、ext_data 这种字段，点进去一看是 JSON 存一堆东西。短期看灵活，后期查询、索引、迁移全是坑。该拆就拆，每个字段要有明确含义，比如 user_status 比 status 好，避免歧义。
类型也不能乱来。明明是枚举值，非要用字符串存‘正常’‘禁用’，不如用 tinyint 配字典表，省空间还方便筛选。
主外键关系有没有理清
有个订单系统，订单明细和商品信息之间没加外键约束，结果删了商品，订单里还能查到记录，数据对不上。评审时得盯着看关联是否完整，级联逻辑是否合理。不是说一定要物理外键，但至少在设计图上标清楚。
索引设计是否到位
常见问题是全表扫描慢得要死，一查发现 where 条件里的字段没加索引。比如按创建时间查日志，create_time 不建索引，百万数据就得等半分钟。复合索引也要注意顺序，把筛选性高的放前面。
CREATE INDEX idx_order_user_time ON orders (user_id, create_time DESC);命名规范统一了吗
同一个业务实体，有人写 order_info，有人写 trade_main，还有人写 purchase_header，三方系统一接，脑壳疼。评审时得统一术语，最好有词汇表，比如用户相关都用 user_ 开头，订单相关用 order_ 开头。
是否考虑了扩展性和性能
比如用户表一开始只想着存手机号，后面要加邮箱、微信 openid，结果字段不够用了。预留几个扩展字段？还是允许动态属性？这些得提前想好。大字段如图片地址、描述文本，要不要单独拆出去？不然主表膨胀太快。
有没有遗漏重要状态流转
退款流程从申请到完成，中间可能有审核中、驳回、部分退等状态。如果模型里只记“已退”或“未退”，后续统计分析就没法做。状态字段要能支撑业务流程回溯，必要时加个操作日志表。
评审不是走过场，一张图定生死。花两个小时拉齐认知，比后期改三个月代码强。