上一篇
数据库里字段怎么命名
数据库字段命名需遵循小写字母、下划线分隔单词，语义明确且与业务相关，避免使用保留字，可添加表名前缀（如user_id）区分
字段命名的核心原则
| 原则分类 | 具体要求 |
|---|---|
| 清晰性 | 名称需直观反映字段含义，避免抽象或歧义（如用user_name而非un） |
| 一致性 | 同一表内命名风格统一，跨表关联字段需遵循相同逻辑（如user_id vs order_id） |
| 简洁性 | 长度适中，避免过长（如customer_address_line_1可简化为address_line1） |
| 兼容性 | 避免使用数据库保留字（如key、date），禁用特殊字符（如空格、@、#） |
| 可扩展性 | 预留潜在业务场景（如status优于is_active） |
命名规范细则
命名风格选择
| 风格类型 | 示例 | 适用场景 |
|---|---|---|
| 蛇形命名法 | user_id |
MySQL、PostgreSQL等主流数据库 |
| 驼峰命名法 | userId |
ORM框架（如Java、Go）生成的代码 |
| 帕斯卡命名 | UserID |
少数企业旧有规范 |
字段类型前缀
| 数据类型 | 推荐前缀 | 示例 |
|---|---|---|
| 主键 | id（如user_id） |
order_id |
| 外键 | fk_（如fk_user_id） |
fk_product_category_id |
| 时间戳 | ts_（如ts_created） |
ts_updated |
| 布尔值 | is_（如is_deleted） |
is_active |
表名前缀与字段关联
| 场景 | 推荐命名方式 | 示例 |
|---|---|---|
| 关联多张表 | tablename_field |
order_amount, user_email |
| 避免歧义 | 添加上下文前缀 | product_price vs order_price |
常见错误与解决方案
错误案例1：模糊命名
- 问题：字段名
code、value缺乏语义 - 解决：改为
error_code、discount_value
错误案例2：使用保留字
- 问题：字段名
key在MySQL中冲突 - 解决：替换为
key_code或access_key
错误案例3：特殊字符与大小写
- 问题：
First Name含空格，XMLData混淆大小写 - 解决：改用
first_name，统一小写（如xml_data）
最佳实践建议
-
命名策略
- 使用
前缀_业务含义结构（如pay_amount） - 关联字段成对命名（如
start_time与end_time） - 状态字段用
state或status而非flag
- 使用
-
团队协作规范
- 建立命名字典（如
addr=address,qty=quantity） - 通过代码审查工具强制命名规则
- 定期同步业务术语变更（如
cart改称shopping_basket）
- 建立命名字典（如
-
历史数据兼容
- 重构时使用
old_前缀标记废弃字段（如old_phone_number） - 通过视图或别名隐藏底层命名复杂度
- 重构时使用
相关问答FAQs
Q1：能否使用中文作为字段名？
A1：尽量避免，中文命名可能导致：
- 编码兼容性问题（如UTF-8与GBK冲突）
- ORM框架映射失败
- 国际化项目维护困难
若必须使用，需确保：
- 数据库字符集支持（如
utf8mb4） - 所有开发工具开启中文支持
- 在代码中添加英文注释（如
CREATE_TIME备注“创建时间”）
Q2：如何规范处理字段名中的缩写？
A2：遵循以下规则：
- 优先全称：用
customer_segment而非cust_seg - 允许约定俗成缩写：如
addr（地址）、qty（数量） - 混合场景处理：若字段由多个单词组成，仅缩写首单词（如
prod_category_id而非p_category_id） - 避免过度缩写：禁止使用
usr（应为user）、doc（应为document）等不明确缩写
