数据库命名规范

✅ 数据库命名规则

类别	命名规则	示例	说明
命名风格	小写字母 + 下划线分隔	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_time、update_time、login_time	清晰表达语义
布尔字段	is_ 前缀命名	is_active	表示真假状态
枚举/状态字段	_type / _status 后缀	user_type、order_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
复制编辑
smart_library

表名：

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	更新时间

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

类别	禁用内容	原因说明
❌ 保留关键字	select、order、group、desc、index 等	这些是 MySQL/SQL 标准语法的一部分，使用时易导致语法冲突
❌ 特殊字符	-、空格、.、#、@、$、%、& 等	非法字符或在 SQL 中具有特殊意义，易出错
❌ 大写字母	User、BookInfo 等	Linux 系统大小写敏感，跨平台易出错，建议全小写
❌ 非英文命名	中文或其他语言（如 用户名, 图书）	跨语言或工具支持差，难以编码管理和协作
❌ 模糊名称	name、time、data	语义不清，建议明确表述（如 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	字段名应带上下文	如：name → user_name，status → order_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_time 比 ctime 更可读也更自解释
🔹16	避免过度嵌套字段（尤其 JSON/文本字段）	除非必要，否则字段结构应尽量扁平化，方便查询与索引
🔹17	提前规划软删除字段（如 is_deleted）	比物理删除更安全，建议所有表统一设计
🔹18	保留统一的审计字段：创建时间、更新时间、创建人、更新人	如 create_time, update_time, created_by, updated_by，便于后期追踪与日志系统对接

---

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

类型	用途与说明
✅ 字段字典	描述每个表的字段、类型、含义
✅ 命名规范手册	团队统一参考的命名规则
✅ ER 图	表与表之间的关系图（实体关系图）
✅ 状态枚举表	定义所有状态字段及对应含义
✅ 自动检查脚本	用于 CI 检测是否存在不规范命名的脚本