数据库命名规范

✅ 数据库命名规则

类别 命名规则 示例 说明
命名风格 小写字母 + 下划线分隔 smart_library 使用项目或业务模块名称
长度限制 最长 64 个字符 - 超出会报错
禁用内容 避免特殊字符和 SQL 保留字 order, test-db 使用需加反引号,建议避免
建议结构 项目名 + 模块名 library_user 避免过度简写,保持可读性

✅ 表名命名规则

类别 命名规则 示例 说明
命名风格 小写字母 + 下划线,使用单数形式 user, book_info 一致性好,避免大小写敏感问题
命名建议 业务实体或模块名称 order_detail 尽量描述清楚该表是干什么的
关联表命名 多对多关系,两个表名按字母顺组合 book_author 避免歧义,提升可读性
临时表 tmp_ 开头 tmp_user_stats 用于临时操作
历史归档表 history__archive 后缀 user_history, order_archive 清晰反映用途

✅ 列名(字段名)命名规则

类别 命名规则 示例 说明
命名风格 小写字母 + 下划线分隔 create_time 统一风格,避免大小写敏感问题
主键 一般命名为 id id 单表唯一主键,推荐 auto_increment
外键 表名(单数) + _id user_id 表示当前字段来自哪个表的主键
时间字段 统一使用 _time 后缀 create_timeupdate_timelogin_time 清晰表达语义
布尔字段 is_ 前缀命名 is_active 表示真假状态
枚举/状态字段 _type / _status 后缀 user_typeorder_status 类型或状态表示
禁用内容 避免 SQL 保留字 select, order, group 如必须使用需加反引号 ``` 包裹

✅ 主键命名规则

类型 命名 说明
单主键 id 所有表主键建议统一使用 id
联合主键 (id1, id2) 少用联合主键,建议改为唯一索引

✅ 外键命名规则

类型 命名方式 说明
外键字段 <referenced_table>_id 例如 user_id 表示引用 user 表
外键约束 fk_<from>_<to> 例如 fk_order_user

✅ 多对多关联表命名规则

表1 表2 关联表名 说明
user role user_role 按照字母顺序组合,表示关联关系
book author book_author 可根据项目复杂度添加额外字段

✅ 示例:完整命名实践

数据库名:

sql 复制代码
sql
复制编辑
smart_library

表名:

sql 复制代码
sql
复制编辑
user、book、book_category、book_author、order、order_detail

表结构示例:

book 表

列名 类型 说明
id INT 主键,自增
title VARCHAR(255) 书名
author_id INT 外键,关联 author
category_id INT 外键,关联 category
publish_time DATETIME 出版时间
is_deleted TINYINT(1) 软删除标记
create_time DATETIME 创建时间
update_time DATETIME 更新时间

✅ 命名规范中的禁用项说明(适用于数据库名 / 表名 / 列名)

类别 禁用内容 原因说明
❌ 保留关键字 selectordergroupdescindex 这些是 MySQL/SQL 标准语法的一部分,使用时易导致语法冲突
❌ 特殊字符 -、空格、.#@$%& 非法字符或在 SQL 中具有特殊意义,易出错
❌ 大写字母 UserBookInfo Linux 系统大小写敏感,跨平台易出错,建议全小写
❌ 非英文命名 中文或其他语言(如 用户名, 图书 跨语言或工具支持差,难以编码管理和协作
❌ 模糊名称 nametimedata 语义不清,建议明确表述(如 user_name, create_time
❌ 冗余命名 user_user, book_table 多余重复词汇,降低可读性(user, book 即可)
❌ 驼峰命名 userName, bookInfo SQL 通常不支持驼峰,且影响脚本自动化处理(如生成器)
❌ 多语言混用 user_时间, book状态 列名中中英文混用,严重影响团队协作及工具兼容性

✅ 数据库设计命名的注意事项(强烈建议采纳)

注意点编号 注意事项 说明与建议
🔹 1 保持命名一致性 整个系统统一采用小写 + 下划线命名风格,避免混用不同风格(如 userName vs user_name
🔹 2 避免使用缩写(除非团队共识) 比如不要用 usr 替代 user,缩写可能造成歧义或阅读障碍
🔹 3 表名不要带冗余后缀 table / tbl user 就够了,不要写成 user_table
🔹 4 字段名应带上下文 如:nameuser_namestatusorder_status
🔹 5 布尔字段以 is_has_ 开头 例如 is_deleted, has_paid,提升代码表达性
🔹 6 时间字段统一加 _time 后缀 如:create_time, update_time, login_time,避免用 date, timestamp 作为字段名
🔹 7 主键字段统一命名为 id 每个表主键统一用 id 命名,便于通用处理工具识别(如 ORM 框架)
🔹 8 外键字段以 <表名>_id 命名 user_id, book_id,提高字段含义清晰度
🔹 9 尽量避免联合主键,使用唯一索引替代 联合主键在外键关联、ORM 映射、性能调优等方面都有弊端
🔹10 不要将列名设计成数据含义 + 单位拼接 (如 priceYuan 单位应在 UI 层处理,字段名应语义通用如 price
🔹11 避免字段类型与含义不符 例如状态字段不应用字符串类型,而应使用枚举或整数(如 TINYINT)
🔹12 使用枚举/状态字段时要定义清晰的值含义 order_status = 1(待付款),2(已付款),应文档中明确标注含义
🔹13 不要在字段名中包含业务逻辑或版本信息 比如 user_v2_email, user_locked_forever,容易失效或耦合
🔹14 表结构设计应避免过度冗余 不要重复存储可通过关联表计算出的信息,优先考虑范式规范(如 3NF)
🔹15 可读性和语义优先于精简 比如:create_timectime 更可读也更自解释
🔹16 避免过度嵌套字段(尤其 JSON/文本字段) 除非必要,否则字段结构应尽量扁平化,方便查询与索引
🔹17 提前规划软删除字段(如 is_deleted 比物理删除更安全,建议所有表统一设计
🔹18 保留统一的审计字段:创建时间、更新时间、创建人、更新人 create_time, update_time, created_by, updated_by,便于后期追踪与日志系统对接

✅ 建议额外配套文档或工具

类型 用途与说明
✅ 字段字典 描述每个表的字段、类型、含义
✅ 命名规范手册 团队统一参考的命名规则
✅ ER 图 表与表之间的关系图(实体关系图)
✅ 状态枚举表 定义所有状态字段及对应含义
✅ 自动检查脚本 用于 CI 检测是否存在不规范命名的脚本
相关推荐
铅笔侠_小龙虾19 分钟前
Docker 实战 -- Mysql
mysql·docker·容器
Britz_Kevin1 小时前
从零开始的云计算生活——番外2,MySQL组复制
数据库·mysql·云计算·生活·#组复制
工藤学编程1 小时前
分库分表之实战-sharding-JDBC绑定表配置实战
数据库·分布式·后端·sql·mysql
一只fish2 小时前
MySQL 8.0 OCP 1Z0-908 题目解析(23)
数据库·mysql
程序猿小D3 小时前
[附源码+数据库+毕业论]基于Spring Boot+mysql+vue结合内容推荐算法的学生咨询系统
数据库·vue.js·spring boot·mysql·毕业设计·推荐算法·学生咨询系统
大菠萝学姐3 小时前
基于Spring Boot和Vue的高校图书馆座位预约系统的设计与实现
java·vue.js·spring boot·后端·python·mysql·vue
叁沐4 小时前
MySQL 10 MySQL为什么有时候会选错索引?
mysql
He.ZaoCha4 小时前
函数-3-日期函数
数据库·sql·mysql
paopaokaka_luck4 小时前
基于Spring Boot+Vue的巴彦淖尔旅游网站(AI问答、腾讯地图API、WebSocket及时通讯、支付宝沙盒支付)
数据库·vue.js·spring boot·websocket·mysql·毕业设计·旅游
{⌐■_■}5 小时前
【软件工程】tob和toc含义理解
前端·数据库·mysql·golang·软件工程·tidb