Schema规范制定：命名规范、数据类型规范、字段长度规范、注释规范

说实话，很多团队一开始做Schema治理，上来就搞工具、搞平台。结果呢？规范没定好，工具再牛也白搭。我见过太多这样的案例了——花了几十万买平台，最后因为命名乱、类型乱、注释乱，数据还是没法用。

所以这一章，咱们就聊聊规范本身。四个核心维度：命名、数据类型、字段长度、注释。把这四个定清楚，你的Schema就稳了一半。

2.1 命名规范：一眼看懂，少走弯路

命名这事，看着简单，其实最容易出乱子。我接手过一个项目，同一个字段在三个表里叫了三个名字：user_id、uid、userId。你想想看，光对齐这个就花了两周。

我个人习惯用snake_case（小写+下划线）。为什么？因为大多数数据库和编程语言都认它，大小写敏感的问题也少。

具体来说，我建议这样定：

• 表名：业务模块_实体名_后缀。比如 fin_payment_records、usr_user_profiles
• 字段名：实体_属性。比如 order_status、product_price
• 主键：统一叫 id，或者 表名_id
• 外键：关联表名_id。比如 user_id、order_id
• 时间字段：动词_at。比如 created_at、updated_at
• 布尔字段：is_/has_ 开头。比如 is_active、has_verified

2.2 数据类型规范：选对类型，省一半空间

数据类型选错了，后果很严重。我见过有人用 VARCHAR(255) 存年龄，用 DECIMAL(10,2) 存状态码。说白了，就是图省事，结果存储空间翻倍，查询性能还差。

我的建议很简单：用最合适的类型，别用最通用的类型。

数据类型	推荐场景	不推荐场景	说明
TINYINT	状态码、枚举值（0-255）	存储大数字	只占1字节，比INT省75%
INT	ID、计数器	手机号（超范围）	4字节，够用就别用BIGINT
BIGINT	订单号、时间戳（毫秒）	普通ID	8字节，别滥用
DECIMAL	金额、精确计算	百分比（用FLOAT也行）	精度可控，但占空间大
VARCHAR	变长字符串	固定长度编码（用CHAR）	按实际长度存储
CHAR	固定长度编码	用户输入文本	定长，查询更快
DATETIME	业务时间	只需要日期	8字节，含时区信息
DATE	生日、下单日期	需要精确到秒	3字节，省空间

2.3 字段长度规范：够用就好，别贪多

字段长度这事，很多人觉得「设大一点总没错」。错！VARCHAR(255) 和 VARCHAR(10) 在存储上确实没区别，但在索引、内存排序、网络传输上，差别大了去了。

我建议按这个原则来：

• 字符串字段：按业务上限定。比如手机号 VARCHAR(20)，邮箱 VARCHAR(100)，别上来就255
• 枚举字段：用 TINYINT 或 SMALLINT，别用字符串存
• 文本字段：超过500字符的，考虑用 TEXT 或 MEDIUMTEXT
• 编码字段：固定长度的用 CHAR，比如国家代码 CHAR(2)

举个例子，我之前做一个电商项目，商品名称字段一开始设了 VARCHAR(500)。后来一查，最长的商品名才120个字符。果断改成 VARCHAR(200)，索引效率提升了不少。

2.4 注释规范：写注释，就是写文档

嗯，这里我要多说两句。很多开发觉得「代码即文档」，但数据库不一样。你想想看，一个表20个字段，半年后谁还记得 status 字段的0、1、2分别代表什么？

我个人的硬性要求是：每个字段必须有注释。包括枚举值的含义。

-- 表注释
COMMENT ON TABLE orders IS '订单主表，记录用户下单信息';

-- 字段注释
COMMENT ON COLUMN orders.order_id IS '订单唯一标识，格式：ORD+年月日+6位流水';
COMMENT ON COLUMN orders.order_status IS '订单状态：0-待支付，1-已支付，2-已发货，3-已完成，4-已取消';
COMMENT ON COLUMN orders.total_amount IS '订单总金额，单位：分，避免浮点精度问题';
COMMENT ON COLUMN orders.created_at IS '创建时间，精确到毫秒';
COMMENT ON COLUMN orders.updated_at IS '最后更新时间，由触发器自动维护';

注释规范我建议包含这几部分：

• 表注释：表的作用、主要关联关系、数据量级
• 字段注释：业务含义、取值范围、单位、格式
• 枚举注释：每个值的含义，最好列全
• 关联注释：外键关系、索引用途

2.5 规范落地：从文档到代码

规范定好了，怎么落地？我建议三步走：

1. 写进开发规范文档：团队统一评审，签字确认
2. 做成模板和脚本：建表语句模板、DDL生成脚本，自动带出规范
3. 纳入CI/CD检查：用工具自动扫描，不符合规范的直接打回

举个例子，我们团队用了一个简单的Python脚本，每次提交DDL之前自动检查：

# 伪代码示例：DDL规范检查
def check_naming(table_name, columns):
    # 检查表名是否snake_case
    if not re.match(r'^[a-z][a-z0-9_]+$', table_name):
        raise Exception(f'表名 {table_name} 不符合snake_case规范')
    
    # 检查字段是否有注释
    for col in columns:
        if not col.comment:
            raise Exception(f'字段 {col.name} 缺少注释')
    
    # 检查字段长度是否合理
    for col in columns:
        if col.type == 'VARCHAR' and col.length > 500:
            raise Exception(f'字段 {col.name} 长度超过500，建议使用TEXT类型')

说白了，规范不是写在文档里吃灰的。要让它变成代码的一部分，变成自动化检查的一部分。这样才真正能省钱。