一个库里有user、users、user_info、t_user四张表，你敢信？这是我上个月真实见到的一家客户的系统，四张表是三拨人不同时期建的，谁也不敢删谁。数据库设计的命名规范，平时没人当回事，乱到一定程度，每一行代码都在给后人挖坑。
表名：单复数统一，别玩前缀花活
要么全用单数order、user，要么全用复数orders、users，选一个坚持到底，别一会儿加t_前缀一会儿不加。表名用完整英文单词，别自创缩写，usr、ord这种缩写省了两个字母，让后面所有人每次都得猜一遍，得不偿失。
字段名：认准一套惯例用到底
最常见的乱源在时间字段：created_at、add_time、create_date、ctime在同一个库里轮番出现。开工第一天就定好惯例，比如统一用created_at、updated_at，写进开发文档，谁也不许自创。再比如金额字段统一用decimal后缀_amount，状态字段统一_status，类型字段统一_type，看见后缀就知道里面装的是什么，比什么命名都值钱。
几个高频错误顺手列出来
- 金额用varchar存，算账时字符串转数字，精度全毁，金额永远用decimal，这是铁律。
- 布尔字段用is_开头却存1和2，不如统一0和1，并把含义写进备注。
- 字段名里带拼音，比如kehuname，中英混搭最让人崩溃。
- 备注不写，半年后连建表的人自己都分不清remark和note有什么区别。
规范这东西不需要多厚，一页纸足够，关键在执行。我们见过最有效的落地办法是把规范配进代码检查工具，提交代码时自动扫描命名不合规的字段语句，不通过就打回。靠人提醒总有疏漏，靠工具卡着，半年下来整个库干干净净，新人入职看两天规范加表结构就能上手干活。
两条建议：项目开工前让开发出一页纸的命名规范，双方确认，验收时照着抽查；接手老系统想整改命名的，只改新增部分别动存量，改老表字段牵一发动全身，动静越小越好。比格网络内部有现成的数据库设计规范清单，客户验收时可以直接拿它当检查表用，一项项过，比凭感觉踏实。
