数据库字段 英文-数据库中字段加星号
数据库表字段命名约定
摘要: 在当前的研发工作中,经常会出现因数据库表格式不规范、数据库表字段格式不规范而影响开发进度的问题。 统一导致数据查询和数据使用效率低下,因此有必要梳理出一套合适的数据库表字段命名规范来解决和优化这些问题。
本文是一个规范文档,包括数据库命名、数据库表命名、数据库表字段命名、SQL语言编码。 对研发中容易出现的问题和常见错误进行梳理和修改,为以后数据库相关的研发做准备。 准备工作。
1. 数据库命名规范
它由26个英文字母(区分大小写)和0-9的自然数(通常不需要)加上一个下划线'_'组成。 命名简洁明了。 多个单词由下划线“_”分隔。 一个项目一个数据库,多个项目使用同一个数据库慎用
2.数据库表命名规范
2.1 数据表命名规范
(1) 由26个英文字母(区分大小写)和0-9的自然数(通常不需要)加上下划线'_'组成,名字简洁明了,多个单词用下划线'_'分隔
(2) 名称全部小写,禁止大写
(3) 禁止使用数据库关键字,如:名称、时间、日期时间、密码等。
(4)表名不要太长(一般不超过三个英文单词)
(5) 表名一般使用名词或动宾短语
(6) 以单数形式表示姓名,例如用employee代替employees
明细表名称为:主表名+字符dtl(明细缩写)
例如:采购订单名称为:po_order,则采购订单明细表为:po_orderdtl
(7)表必须填写描述信息(使用SQL语句创建表时)
2.2 命名约定
①模块_+功能点示例:alllive_log alllive_category
②功能点示例:直播留言
③总表示例: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.数据库字段命名规范
3.1 字段命名约定
(1) 由26个英文字母(区分大小写)和0-9的自然数(通常不需要)加上下划线'_'组成,名字简洁明了,多个单词用下划线'_'分隔
(2) 名称全部小写,禁止大写
(3) 该字段必须填写描述信息
(4) 禁止使用数据库关键字,如:名称、时间、日期时间密码等。
(5) 字段名一般使用名词或动宾短语
(6) 使用的字段名称必须通俗易懂,一般不超过三个英文单词
(7) 为表的列命名时,不要重复表名
例如,避免在名为 employee 的表中使用名为 employee_lastname 的字段
(8) 不要在列名中包含数据类型
(9) 字段命名使用全称,禁止缩写
3.2 命名约定
①名词示例:user_id user_name 性别
②动宾短语示例: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(256) 与 varchar(16) 一起使用
IP地址使用int类型
定长类型最好使用char,例如:邮政编码(postcode)
能用tinyint就不要用smallint,int
最好给每个字段一个默认值,最好不为null
(4) 适当的字段类型节省空间
字符转换成数字(能转换的最好转换,这样也节省了空间,提高了查询性能)
避免使用NULL字段(NULL字段难以查询优化,NULL字段上的索引需要额外的空间,NULL字段上的复合索引无效)
使用较少的文本类型(尝试使用 varchar 而不是文本字段)
3.5 数据库各字段规范说明
(1)尽量符合第三范式(3NF)的标准
表中每个值只能表示一次
表中的每一行都应该唯一标识
表不应存储依赖于其他键的非键信息
(2)如果该字段实际关联了其他表的关键字,没有设计成外键引用,需要建索引
(3)如果该字段与其他表中的字段有关联,则需要建索引
(4)如果字段需要进行模糊查询以外的条件查询,则需要建立索引
(5) 除了主键允许建立聚集索引外,其他字段建立的索引必须是非聚集索引
4.SQL语言编码规范
4.1 案例说明
(1) 所有关键字必须大写,如:INSERT、UPDATE、DELETE、SELECT及其子句、IF...ELSE、CASE、DECLARE等。
(2) 除用户变量外的所有函数及其参数必须大写
(3)定义变量时使用的数据类型必须是小写
4.2 注意事项
注释可以包含在批处理中。 在触发器和存储过程中加入描述性注释会大大增加文本的可读性和可维护性。 本规范建议:
(1) 注释以英文为主。 在实际应用中,发现英文环境下无法使用中文注释的SQL语句版本。 为避免后续版本执行过程中出现一些异常错误,建议使用英文注释
(2) 评论应尽可能详细和全面。 在创建每个数据对象之前,应该详细描述对象的功能和用途。 应该解释一下传入参数的含义。 如确定了取值范围数据库字段 英文,还应说明。 对于具有特定含义的变量(如boolean类型变量),应给出每个值的含义
(3) 注释语法:单行注释、多行注释
单行注释:注释前有两个连字符(--),可用于变量和条件从句
多行注释:符号之间的内容为注释内容,完整操作建议使用该类型的注释
(4) 注释简明扼要,应描述清楚
(5) 函数注解:
在编写函数文本(例如触发器、存储过程和其他数据对象)时,您必须为每个函数添加适当的注释。 注释主要是多行注释,主要结构如下:
创建过程 sp_xxx