数据库存命名规则
数据库表字段命名规范
一、
1. 如无备注，则表中的第一个id字段一定是主键且为自动增长；
2. 如无备注，则数值类型的字段请使用UNSIGNED属性；
3. 如无备注，排序字段order_id在程序中默认使用降序排列；
4. 如无备注，所有字段都设置NOT NULL，并设置默认值；
5. 如无备注，所有的布尔值字段，如is_hot、is_deleted，都必须设置一个默认值，并设为0；
6. 所有的数字类型字段，都必须设置一个默认值，并设为0；
7. 针对varchar类型字段的程序处理，请验证用户输入，不要超出其预设的长度；
8. 建表时将数据字典中的字段中文名和属性备注写入数据表的备注中(“PK、自动增长”不用写)；
9. 如无说明，建表时一律采用innodb引擎；
二、【常用表名约定】
0. 说明：表前缀用项目名称首字母缩写；所以表名都小写，单词之间用下划线分开，单词都用单数形式
1. user – 用户
2. category – 分类
3. goods – 商品、产品等一切可交易网站的物品都用此命名
4. good_gallery – 物品的相册
5. good_cate – 物品的分类，除了单独作为表名，其他地方分类单词一律用缩写cate
4. attr – 属性
5. article – 文章、新闻、帮助中心等以文章形式出现的，一般都用此命名
6. cart – 购物车
7. feedback – 用户反馈
8. order – 订单
9. site_nav – 包括页头和页尾导航
10. site_config – 系统配置表
11. admin – 后台用户 【RBAC标准表】
12. role – 后台用户角色【RBAC标准表】
13. access – 后台操作权限，相当于action【RBAC标准表】
14. role_admin – 后台用户对应的角色【RBAC标准表】
15. access_role – 后台角色对应的权限【RBAC标准表】
16. 待续
三、【常用列名约定】
1. 表名_id – 通常用作外键命名
2. cid – 特殊的编号，带有元数据，方便关联查询，你可以把它理解成类别(层次)编号。举个例子，产品在分类时，往往需要将其归类到子分类下，相应的字段中也一般只记录子分类的id，这时若需要知道该产品属于哪个主分类，就需要通过子分类信息再查询到主分类信息，这是比较麻烦的，cid字段就是要解决这个问题。一般的站点几十个分类肯定是够用了，所以这里假设某一主分类的cid为11，则子分类的cid从1101开始编号，处理时只需截取前两位数值便可知道该产品属于哪一个主分类了。
3. add_time – 添加时间、上架时间等
4. last_time – 最后操作时间，如登录、修改记录
5. expire_time – 过期时间
6. name – 商品名称、商家名称等，不要跟title混用，title只用于文章标题、职称等
7. price – 价格
8. thumb – 只要是列表页面中的窗口图，一律用此命名
9. image_src – 相册中的图片地址一律用此命名，不要出现各种img,image,img_url,thumb_url等
10. head_thumb – 用户头像， 虽然有点长，一定要遵守。不要出现上述情况
11. image_alt – 相册中图片的alt属性
12. desc – 描述、简介，比如goods_desc，不要出现goods_txt这种
13. details – 详情、文章内容等
14. order_id – 排序
15. telephone – 座机号码
16. mobile – 手机号码
17. phone – 当不区分手机和座机时，请用phone命名
18. address – 地址，单独出现不要用addr缩写，组合出现时需用缩写，比如mac地址，mac_addr
19. zipcode – 邮编
20. region – 地区，大的区域，比如记录杭州市、温州市等
21. area – 区域，小的，比如上城区，江干区等
22. avg_cost – 人均消费
23. 待续
摘要：当前研发工作中经常出现因数据库表、数据库表字段格式不规则而影响开发进度的问题，在后续开发使用原来数据库表时，也会因为数据库表的可读性不够高，表字段规则不统一，造成数据查询，数据使用效率低的问题，所以有必要整理出一套合适的数据库表字段命名规范来解决优化这些问题。
本文是一篇包含了数据库命名、数据库表命名、数据库表字段命名及SQL语言编码的规范文档，针对研发中易产生的问题和常见错误做了一个整理和修改，为日后涉及到数据库相关的研发工作做好准备。
一、数据库命名规范
采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成，命名简洁明确，多个单词用下划线'_'分隔，一个项目一个数据库，多个项目慎用同一个数据库
二、数据库表命名规范
2.1数据表命名规范
（1）采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成，命名简洁明确，多个单词用下划线'_'分隔
（2）全部小写命名，禁止出现大写
（3）禁止使用数据库关键字，如：name，time ，datetime，password等
（4）表名称不应该取得太长（一般不超过三个英文单词）
（5）表的名称一般使用名词或者动宾短语
（6）用单数形式表示名称，例如，使用 employee，而不是 employees
明细表的名称为：主表的名称+字符dtl（detail缩写）
例如：采购定单的名称为：po_order，则采购定单的明细表为：po_orderdtl
（7）表必须填写描述信息（使用SQL语句建表时）
2.2命名规范
①模块_+功能点 示例：alllive_log alllive_category
②功能点 示例：live message
③通用表 示例：all_user
2.3待优化命名示例
①冗余：
错误示例：yy_alllive_video_recomment yy_alllive_open_close_log
说明：去除项目名，简化表名长度，去”yy_”
②相同类别表命名存在差异，管理性差
错误示例：yy_all_live_category yy_alllive_comment_user
说明：去除项目名，统一命名规则，均为”yy_alllive_”开头即可
③命名格式存在差异
错误示例：yy_showfriend yy_user_getpoints yy_live_program_get
说明：去除项目名，统一命名规则，动宾短语分离且动宾逻辑顺序统一
三、数据库字段命名规范
3.1字段命名规范
（1）采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成，命名简洁明确，多个单词用下划线'_'分隔
（2）全部小写命名，禁止出现大写
（3）字段必须填写描述信息
（4）禁止使用数据库关键字，如：name，time ，datetime password 等
（5）字段名称一般采用名词或动宾短语
（6）采用字段的名称必须是易于理解，一般不超过三个英文单词
（7）在命名表的列时，不要重复表的名称
例如，在名employe的表中避免使用名为employee_lastname的字段
（8）不要在列的名称中包含数据类型
（9）字段命名使用完整名称，禁止缩写
3.2命名规范
①名词 示例：user_id user_name sex
②动宾短语 示例：is_friend is_good
3.3待优化命名示例
①大小写规则不统一
错误示例：user_id houseID
说明：使用统一规则，修改为”user_id”，”house_id”
②加下划线规则不统一
错误示例：username userid isfriend isgood
说明：使用下划线进行分类，提升可性，方便管理，修改为”user_name”，”user_id”，”is_friend”，”is_good”
③字段表示不明确
错误示例：uid pid
说明：使用完整名称，提高可读性，修改为”user_id”，”person_id”
3.4字段类型规范
（1）所有字段在设计时，除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外，必须有默认值，字符型的默认值为一个空字符值串’’，数值型的默认值为数值0，逻辑型的默认值为数值0
（2）系统中所有逻辑型中数值0表示为“假”，数值1表示为“真”，datetime、smalldatetime类型的字段没有默认值，必须为NULL
（3）用尽量少的存储空间来存储一个字段的数据
使用int就不要使用varchar、char，
用varchar(16)就不要使varchar(256)
IP地址使用int类型
固定长度的类型最好使用char，例如：邮编(postcode)
能使用tinyint就不要使用smallint，int
最好给每个字段一个默认值，最好不能为null
（4）用合适的字段类型节约空间
字符转化为数字(能转化的最好转化，同样节约空间、提高查询性能)
避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效)
少用text类型(尽量使用varchar代替text字段)
3.5数据库中每个字段的规范描述
（1）尽量遵守第三范式的标准（3NF）
表内的每一个值只能被表达一次
表内的每一行都应当被唯一的标示
表内不应该存储依赖于其他键的非键信息
(2)如果字段事实上是与其它表的关键字相关联而未设计为外键引用，需建索引
(3)如果字段与其它表的字段相关联，需建索引
(4)如果字段需做模糊查询之外的条件查询，需建索引
(5)除了主关键字允许建立簇索引外，其它字段所建索引必须为非簇索引
四、SQL语言编码规范
4.1大小写规范
（1）所有关键字必须大写，如：INSERT、UPDATE、DELETE、SELECT及其子句，IF……ELSE、CASE、DECLARE等
（2）所有函数及其参数中除用户变量以外的部分必须大写
（3）在定义变量时用到的数据类型必须小写
4.2注释
注释可以包含在批处理中，在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可维护性，本规范建议：
（1）注释以英文为主，实际应用中，发现以中文注释的SQL语句版本在英文环境中不可用，为避免后续版本执行过程中发生某些异常错误，建议使用英文注释
（2）注释尽可能详细、全面创建每一数据对象前，应具体描述该对象的功能和用途，传入参数的含义应该有所说明，如果取值范围确定，也应该一并说明，取值有特定含义的变量（如boolean类型变量），应给出每个值的含义
（3）注释语法：单行注释、多行注释
单行注释：注释前有两个连字符（--）对变量、条件子句可以采用该类注释
多行注释：符号之间的内容为注释内容，对某项完整的操作建议使用该类注释
（4）注释简洁，同时应描述清晰
（5）函数注释：
编写函数文本--如触发器、存储过程以及其他数据对象--时，必须为每个函数增加适当注释，该注释以多行注释为主，主要结构如下：
CREATE PROCEDURE sp_xxx
