MYSQL数据库字段命名及设计规范

1. 设计原则

---

(1) 标准化和规范化

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但ThirdNormalForm（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF标准的数据库的表设计原则是：“OneFactinOnePlace”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF数据库就可能有两个表：Customer和Order。Order表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer表里包含该客户信息的那一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。

(2) 数据驱动

采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源（文件、XML文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

(3) 考虑各种变化

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

2. 数据库涉及字符规范

---

采用26个英文字母(区分大小写)和0-9这十个自然数，加上下划线’_'组成,共63个字符，不能出现其他字符(注释除外)。
注意事项：
(1) 以上命名都不得超过30个字符的系统限制.变量名的长度限制为29(不包括标识字符@)。
(2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名，绝对不要在对象名的字符之间留空格。
(3) 小心保留词，要保证你的字段名没有和保留词、数据 库系统或者常用访问方法冲突。
(4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。

3. 数据库命名规范

---

数据库，数据表一律使用前缀。

正式数据库名使用小写英文以及下划线组成，尽量说明是那个应用或者系统在使用的。比如:

web_19floor_net
web_car

备份数据库名使用正式库名加上备份时间组成，如：

web_19floor_net_20070403
web_car_20070403

4. 数据库表命名规范

---

数据表名使用小写英文以及下划线组成，尽量说明是那个应用或者系统在使用的。
相关应用的数据表使用同一前缀，如 论坛的表使用cdb_前缀，博客的数据表使用supe_前缀。前缀名称一般不超过5字，
比如：

web_user
web_group
supe_userspace

备份数据表名使用正式表名加上备份时间组成，如：

web_user_20070403
web_group_20070403
supe_userspace_20070403

5. 字段命名规范

---

字段名称使用单词组合完成,首字母小写，后面单词的首字母大写，最好是带表名前缀。
如 web_user 表的字段:

user_Id
user_Name
user_Password

表与表之间的相关联字段要用统一名称,
如 web_user 表 里面的 user_Id 和 web_group 表里面的 user_Id 相对应

（大叔旁白）
按《阿里Java开发规范》中的约定，不得使用大写字母，不得连写两个单词。

6.字段类型规范

---

规则：用尽量少的存储空间来存 数一个字段的数据。比如：

• 能用int的就不用char或者varchar；
• 能用tinyint的就不用int；
• 能用varchar(20)的就不用varchar(255)；
• 时间戳字段尽量用int型，如gmt_create:表示从 ‘1970-01-01 08:00:00’ 开始的int秒数，采用英文单词的过去式；gmtCreated:表示datetime类型的时间，即形如 '1980-01-01 00:00:00’的时间串，Java中对应的类型为Timestamp

（大叔旁白）
按《阿里Java开发规范》中的约定：
表必备三字段：id, gmt_create, gmt_modified。
说明：其中 id 必为主键，类型为 unsigned bigint、单表时自增、步长为 1；分表时改为从TDDL Sequence 取值，确保分表之间的全局唯一。gmt_create, gmt_modified 的类型均为date_time 类型。

7.数据库设计文档规范

---

所 有数据库设计要写成文档,文档以模块化形式表达.大致格式如下：

'-------------------------------------------
’ 表 名： web_user
’ 作者： Aeolus(傻鱼)
’ 日期： 2007-04-11
’ 版 本： 1.0
’ 描述： 保存用户资料
’ 具体内容：
’ UserID int,自动增量 用户 代码
’ UserName char(12) 用户名字
’ …
'--------------------------------------------

8. 索引使用原则

---

(1) 逻辑主键使用唯一的成组索引，对系统键(作为存储过程)采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
(2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
(3) 不要索引blob/text等字段，不要索引大型字段(有很多字符)，这样作会让索引占用太多的存储空间。
(4) 不要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

9. sql语句规范

---

所有sql关键词全部大 写,比如SELECT，UPDATE，FROM，ORDER BY等，所有的表名和库名都要用引号包含
如:

SELECT COUNT(*) FROM `cdb_members` WHERE `user_name` = 'aeolus';

（大叔旁白）
《阿里Java开发规范》并未有上述约定，倒是下面的约定更重要，建表时需要注意。
6. 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
说明：（概念解释）学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，则为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。
7. 【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

10.其他设计技巧

---

(1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
(2) 使用常用英语(或者其他任何语言) 而不要使用编码或者拼音首字母缩写
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码或者拼音首字母缩写，可以在旁边附上用户知道的英语。
(3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access) 、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
(4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
(5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2个版本，犯错的机会将大大减少。
(6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
(7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

---

以上内容是转载自CSDN博客文章。参照《阿里巴巴Java开发手册》做了补充。