数据库表字段命名规范

10 篇文章 0 订阅
10 篇文章 0 订阅

数据库表字段命名规范

数据库表字段命名规范

摘要:当前研发工作中经常出现因数据库表、数据库表字段格式不规则而影响开发进度的问题,在后续开发使用原来数据库表时,也会因为数据库表的可读性不够高,表字段规则不统一,造成数据查询,数据使用效率低的问题,所以有必要整理出一套合适的数据库表字段命名规范来解决优化这些问题。

本文是一篇包含了数据库命名、数据库表命名、数据库表字段命名及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 

  • 1
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库设计命名规范 引言 目前航运系统产品中的部分数据库命名上存在不规范的情形,为进一步规范系统开 发过程中数据字段等实体的命名,特制定本规范要求在后续新增字段时,需要 严格按照本规范执行。 命名规则 1. 数据库名称以"所属子系统简称"+"所属模块简称"打头,如"SH_CP_CARGO",示此 数据为航运子系统合同管理模块的合同货载; "子系统简称 "备注说明 "模块简称 "备注说明 " "SH "航运子系统 "BGT "预算管理 " " "  " " " " " "INF "市场信息 " " " "EST "航次估算 " " " "CP "合同管理 " " " "VYG "航次任务 " " " "AMI "船舶报文 " " " "CML "商务核算 " " " "STA "统计报 " " " "PI "保险理赔 " " " "FI "财务接口 " " " "BASE "基础代码 " " " "FM "文件管理 " "XT "系统基础平 "  "  " " "台 " " " 子系统及模块简称 2. 数据库名按英文(而不是汉语拼音)进行取名,尽量用全名,如果名由几个单词 组成,则单词间用下划线("_")分割,如SH_BASE_BANK等 ; 3. 名限制在30个字符内。当的全名超过30字符时,可用缩写来减少名的长度,如 SH_CP_OIL_INFO等 ; 4. 关连命名规则为 A_Re _B,RE是Relative的缩写,如: SH_CP_USER_RE_ SH_CP_FORM。 字段命名规则 1. 字段名为有意义的单词,或单词缩写 ; 2. 如果字段由几个单词组成,则单词间用下划线("_")分割,如client_id,post_cod e等 ; 3. 字段名限制在30个字符内。当字段名超过30字符时,可用缩写来减少字段名的长度, 如description --> desc;information --> info;address --> addr等 ; 4. 对于数据之间关联冗余的字段,需要与源数据中的字段类型、长度保持一致,如 :船舶信息中有"船舶编号VESSEL_CD"字段,在合同、航次任务等相应的业务 中都会冗余"船舶编号VESSEL_CD",此时合同、航次任务中的船舶编号字段需要 保持与船舶信息一致; 5. 对于数值型字段类型,精确一般建议如下: 1) 示金额数据时,最少需要精确到小数点5位 ,字段类型设置如:NUMBER(10,5); 2) 示百分比数值时,最少需要精确到小数点后5位,字段类型设置如:NUMBER(1 0,5),示数值时为97.872%; 6. 对于时间日期类字段时,一般约定如下: 1) 只需要记录到年月日时,字段名称中用"DATE"标识,字段类型设置为DATE,如CR EATE_DATE; 2) 需要记录到年月日以及时间时,字段名称中用"TIME"标识,字段类型设置为TIM ESTAMP,如PAY_TIME。 7. 对于字符串类字段,一般约定如下: 1) 字段的数据量在4000英文字符以内的(一个汉字两个英文字符),字段数据类型 采用VARCHAR2(XX),字段长度根据实际情况设置; 2) 字段的数据量在4000英文字符以上的,字段数据类型采用CLOB。 索引命名规则 1. 索引须按照IDX_table_<table>_<column>,其中<table>是建立索引的名,<colum n>是建立索引的字段名 ; 2. 索引名限制在30个字符内,当索引名超过30字符时,可用缩写来减少索引名的长度, 如description --> desc;information --> info;address --> addr等 。 主建、外键命名规则 1. 主键按照PK_<table>的规则命名,其中<table>为数据库名,如:PK_SH_ACCIDEN T; 2. 唯一键按照UK_<table>_<column>的规则命名,其中<table>为数据块名,<colum n>为字段名 ; 3. 外键按照FK_<pppp>_<cccc>_<nn>的规则命名,其中<pppp>为父名,<cccc>为子 名,<nn>为序列号 。 注释 1. 名必须加注释。 2. 字段名必须加注释。 ----------------------- 数据库设计命名规范全文共3页,当前为第1页。 数据库设计命名规范全文共3页,当前为第2页。 数据库设计命名规范全文共3页,当前为第3页。
此规范可有效提高SQL代码的可读性及性能,降低维护成本 一、文档说明 1.1 文档目的 1.2 术语定义 二、数据库对象命名规则 2.1 对象命名规则 2.2 视图对象命名规则 2.3 物化视图对象命名规则 2.4 序列对象命名规则 2.5 触发器对象命名规则 2.6 主键对象命名规则 2.7 外键对象命名规则 2.8 唯一性索引对象命名规则 2.9 非唯一性索引对象命名规则 2.10 存储过程对象命名规则 2.11 临时命名规则 2.12 转储命名规则 2.13 分区命名规则 三、字段命名规范 3.1 字段命名规范 3.2 字段类型选择规范 四、SQL开发的规则 4.1 SQL语句统一为大写字母 4.2 禁止使用 SELECT * 操作 4.3 禁止使用 SELECT COUNT(*) 操作 4.4 规范的连接顺序 4.5 使用有意义的别名 4.6 多连接限制 4.7 使用绑定变量 4.8 序列的创建需要添加CACHE 4.9 分批提交大事务 五、PL/SQL开发的规则 5.1 PLSQL通用规则 5.2 PLSQL变量命名规范 5.3 PLSQL异常处理 六、索引创建的指引规则 6.1 索引对象命名规则 6.2 索引创建的一些基本规则 6.3 索引使用的一些基本规则 附录一(性能相关事项) 7.1 让SQL走合理索引,避免全扫描 7.2 避免类型转换 7.3 限制查询的时间范围 7.4 UNION&UNION; ALL的使用原则 7.5 LIKE的使用原则 7.6 避免在索引字段上添加函数 7.7 引入工作概念 7.8 定期清理或归档中的垃圾数据 7.9 使用分区 7.10 其他注意点
数据库设计命名规范全文共6页,当前为第1页。数据库设计命名规范全文共6页,当前为第1页。 数据库设计命名规范全文共6页,当前为第1页。 数据库设计命名规范全文共6页,当前为第1页。 数据库设计命名规范 版本: V1.0 日期: 2015-11-30 拟定: 审核: 科大讯飞 教育产品事业部 数据库设计命名规范全文共6页,当前为第2页。数据库设计命名规范全文共6页,当前为第2页。 数据库设计命名规范全文共6页,当前为第2页。 数据库设计命名规范全文共6页,当前为第2页。 修订记录 时间 版本 修改点 修改人 目 录 1 目的 3 2 数据库命名规范 3 3 数据库命名规范 3 4 字段命名规范 4 5 设计规范 4 6 索引命名规范 5 7 主键、外键命名规范 5 目的 此规范包括数据库命名规范命名规范字段命名规范设计规范;适用对数据库设计命名规范全文共6页,当前为第3页。数据库设计命名规范全文共6页,当前为第3页。象开发、设计、测试人员。 数据库设计命名规范全文共6页,当前为第3页。 数据库设计命名规范全文共6页,当前为第3页。 数据库命名规范 数据库用户名应包含"项目编号+"_"+"子系统编号"。如:"epsp_safety" 数据库名均以英文小写与下划线组合。 数据库字符编码:utf8。 数据库命名规范 数据库命名以是名词形式且都为小写。 名前应该加上前缀,的前缀一个用系统或模块的英文名称缩写,前缀全部小写。如: 数据库名应该有意义,并且易于理解,最好使用可以达功能的英文单词缩写,如果用英文单词示,建议使用完整的英文单词名不可以太长,最好不要超过3个英文单词长度(22个字母)。 在数据库命名时应该用英文单词的单数形式,如员工命名:应该为employee而不是employees。 如果是后台命名时应该在名基础上加上后缀 _b或_base。 在创建完成前,应该为添加的注释。 字段命名规范 字段名为小写。 数据库设计命名规范全文共6页,当前为第4页。数据库设计命名规范全文共6页,当前为第4页。字段名为有意义的单词,或单词缩写数据库设计命名规范全文共6页,当前为第4页。 数据库设计命名规范全文共6页,当前为第4页。 如果字段由几个单词组成,则单词间用下划线("_")分割。 字段名限制在30个字符内。当字段名超过30字符时,可用缩写来减少字段名的长度,如information->info;address -> addr等。 系统中所有属于内码,即仅用于标识唯一性和程序内部用到的标识性字段字段名称建议取为id,采用类型为整型或长整型。 系统中属于是业务内的编号字段,代一定业务信息,建议字段命名为code ,如工作单编号。 不要在数据库字段(列名)中包含数据类型,如:datetime。 不要在数据库字段(列名)命名时重复名,可以使用名首字母或缩写(不包含数据库名前缀)。 不要在数据库字段(列名)命名时,使用数据库关键字,如:name,time ,datetime ,password 等。 设计规范 所有字段在设计时,除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary、varbinary外,必须有默认值。字符型的默认值为一个空字符值串'';数值型的默认值为数值0;逻辑型的默认值为数值0;其中:系统中所有逻辑型中数值0示为"假";数值1示为"真"。datetime、smalldatetime类型的字段没有默认值时,必须为NULL。 当字段定义为字符串形时建议使用varchar而不用nvarchar。注:在MySQL5.0以上的版本中,varchar数据类型的长度支持到了65535,也就是说可以存放65532个字节的数据,起始位和结束位占去了3个字节 建议在大 数中含有如下字段 数据库设计命名规范全文共6页,当前为第5页。数据库设计命名规范全文共6页,当前为第5页。字段数据库设计命名规范全文共6页,当前为第5页。 数据库设计命名规范全文共6页,当前为第5页。 说明 类型 默认值 CreatorID 创建者 int 0 CreatedTime 创建时间 Datetime NULL 字段的描述 字段必须填写描述信息(注释) 尽量遵守第三范式的标准(3NF) 内的每一个值只能被达一次(列名不重复)内的每一行都应当被唯一的标示(标识唯一性,如自动增长主键) 内不应该存储依赖于其他键的非键信息 索引命名规范 索引须按照IDX_table_<column>_<column>,其中<table>是建立索引的名,<colum
数据库设计规范 数据库的重要性不⾔⽽喻。对程序员来说跟数据库打交道更是家常便饭。数据库给开发带来了巨⼤的便利。我们或多或少的知道⼀些数据库 设计规范,但并不全⾯。今天我就简单整理⼀下,帮⾃⼰做个总结梳理,也希望可以帮到⼩伙伴们。 数据库设计规范包括命名规范、库基础规范、字段规范、索引规范和SQL设计规范。 1. 命名规范 1.1 库名、名、字段名禁⽌使⽤MySQL保留字。 1.2 库名、名、字段名使⽤常⽤英语⽽不要使⽤编码,需见名知意,命名与业务、产品线等相关联。 中⽂词汇的英语翻译可以参考常⽤术语来选择相应的英⽂词汇。 1.3 库名、名、字段名必须是名词的复数形式,并且使⽤⼩写字母,多个名词采⽤下划线分割单词MySQL有配置参数lower_case_table_names=1,即库名以⼩写存储,⼤⼩写不敏感。如果是0,则库名以实际情况存储,⼤⼩写敏 感;如果是2,以实际情况存储,但以⼩写⽐较。 如果⼤⼩写混合使⽤,可能存在abc、Abc、ABC等多个共存,容易导致混乱。 字段名显⽰区分⼤⼩写,但实际使⽤时不区分,即不可以建⽴两个名字⼀样但⼤⼩写不⼀样的字段。 为了统⼀规范, 库名、名、字段名使⽤⼩写字母,不允许-号。 1.4 库名、名、字段名禁⽌超过32个字符。 库名、名、字段名⽀持最多64个字符,但为了统⼀规范、易于辨识以及减少传输量,禁⽌超过32个字符 1.5 索引命名规则 索引按照idx_table_column1_column2。其中table是建⽴索引的名,column1和column2是建⽴索引的字段名。 索引名限制在32个字符内。当索引名超过32字符时,可⽤缩写来减少索引名的长度,如description --> desc;information --> info; address --> addr等。 1.6 主键、外键命名规则 主键按照PK_table的规则命名,其中table为数据库名。 唯⼀键按照UK_table_column的规则命名。其中table为数据块名,column为字段名。 外键按照FK_parent_child_nn的规则命名。其中parent为⽗名,child为⼦名,nn为序列号。 2. 库基础规范 2.1 使⽤InnoDB存储引擎。 MySQL 5.5版本开始默认存储引擎就是InnoDB,5.7版本开始,系统都放弃MyISAM了。 2.2 字符集使⽤UTF8MB4字符集,校验字符集使⽤utf8mb4_general_ci。 UTF8字符集存储汉字占⽤3个字节,存储英⽂字符占⽤⼀个字节 校对字符集使⽤默认的utf8mb4_general_ci。特别对于使⽤GUI⼯具设计结构时,要检查它⽣成的SQL定义 连接的客户端也使⽤utf8,建⽴连接时指定charset或SET NAMES UTF8;。 如果遇到EMOJ等情符号的存储需求,可申请使⽤UTF8MB4字符集 2.3 所有都要添加注释,除主键外的字段都需要添加注释 类status型需指明主要值的含义,如'0-离线,1-在线' 2.4 控制单字段数量 单字段数上限30左右,再多的话考虑垂直分,⼀是冷热数据分离,⼆是⼤字段分离,三是常在⼀起做条件和返回列的不分离。 字段控制少⽽精,可以提⾼I/O效率,内存缓存更多有效数据,从⽽提⾼响应速度和并发能⼒,后续ALTER TABLE也更快。 2.5 所有都必须显式指定主键 主键尽量采⽤⾃增⽅式,InnoDB实际是⼀棵索引组织,顺序存储可以提⾼存取效率,充分利⽤磁盘空间。还有对⼀些复杂查询可能需 要⾃连接来优化时需要⽤到。 只有需要全局唯⼀主键时,使⽤外部⾃增id服务 如果没有主键或唯⼀索引,UPDATE/DELETE是通过所有字段来定位操作的⾏,相当于每⾏就是⼀次全扫描 少数情况可以使⽤联合唯⼀主键,需与DBA协商 对于主键字段值是从其它地⽅插⼊(⾮⾃⼰使⽤AUTO_INCREMENT⽣产),去掉AUTO_INCREMENT定义。⽐如⼀些31天、历史⽉ 份上,不要AUTO_INCREMENT属性;还有,必须通过全局id服务获取的主键,也要去掉AUTO_INCREMENT定义。 2.6 不强制使⽤外键参考 即使2个字段有明确的外键参考关系,也不使⽤FOREIGN KEY,因为新纪录会去主键做校验,影响性能。 2.7 适度使⽤视图,禁⽌使⽤存储过程、触发器和事件 使⽤视图⼀定程度上也是为了降低代码⾥SQL的复杂度,但有时候为了视图的通⽤性会损失性能(⽐如返回不必要的字段)。 存储过程(PROCEDURE)虽然可以简化业务端代码,在传统企业写复杂逻辑时可能会⽤到,⽽在互联⽹企业变更是很频繁的,在分库分 的情况下要升级⼀个存储过程相当

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值