数据库设计命名规范

2018-08-08  本文已影响0人  3d7be2e0434d

数据库设计不合理引发的问题

1.数据库表、数据库表字段格式不规则而影响开发进度

2.数据库表的可读性不够高,表字段规则不统一,造成数据查询,数据使用效率低

一、数据库命名规范

采用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)用尽量少的存储空间来存储一个字段的数据

(4)用合适的字段类型节约空间

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)函数注释: 编写函数文本--如触发器、存储过程以及其他数据对象--时,必须为每个函数增加适当注释,该注释以多行注释为主

上一篇下一篇

猜你喜欢

热点阅读