数据库表字段命名规范
数据库字段名称命名规则

数据库字段名称命名规则
数据库字段名称命名规则是数据库设计规范中的重要内容之一。
一个好的命名规则可以帮助开发人员更好地理解数据库表中的字段,提高代码的可读性和可维护性。
下面是常见的数据库字段名称命名规则:
1. 命名规则:通常采用全小写字母和下划线的方式进行命名,字段名长度最多为 32 个字符,禁止超过 32 个字符。
2. 禁使 MySQL 保留字:在命名规则中,禁使 MySQL 保留字,例如_、auto_、master_等。
3. 业务或产品线相关:字段名应该与业务或产品线相关,以便更好地理解字段的含义和用途。
4. 采用英语命名:字段名应该采用英语命名,以便更好地理解其含义。
如果英语翻译可以参考常术语来选择相应的英语单词。
5. 字段名必须是名词的复数形式:字段名必须是名词的复数形式,以便更好地描述字段的含义和用途。
6. 多个名词采下划线分割单词:如果字段名包含多个名词,应该采用下划线将它们分割开。
7. 命名与实际情况相符:在命名规则中,应该尽可能命名与实际情况相符,例如将用户 ID 字段命名为 user_id。
8. 避免使用单个字符或特殊字符:在命名规则中,应该避免使用单个字符或特殊字符,以免导致字段名混淆或无法正确解析。
9. 命名一致:在多个表中使用相同的字段时,应该遵循一致的
命名规则,以便更好地理解数据之间的关系。
不同的数据库管理系统 (DBMS) 可能有不同的命名规则,因此在实际开发中应该根据实际情况进行命名。
数据库命名规范

数据库命名规范一、数据库命名规范:为了简化数据处理,需要统一数据库表及其数据字段的命名规则,规约如下:数据表命名方式:[前缀]_[表存储内容简称],字母大写系统类表:SYS_XXXX基础数据表:ELE_XXXX业务表:子系统简称_XXXX视图命名方式:VW_[前缀]_[视图内容简称],字母大写系统类视图:VW_SYS_XXXX业务类视图:VW_子系统简称_XXXX存储过程命名方式:(不推荐使用存储过程或函数)字段定义字段命名方式:(建议延续现在的命名方式和命名,针对性修改)需要给出字段的中文名需要给出字段的用途描述对于是Boolean(bit)型的字段,分别表达true和false的取值含义对于枚举类型,如果其值不在基础数据表中维护,则需要给出各个枚举值以及含义。
对于字段类型,推荐采用SQLServer、Oracle、DB2兼容的类型。
数据库Schema设计系统Schema:包括系统管理和数据字典,系统Schema不分年度设立其它系统Schema,如总帐系统Schema,需要分年度设立。
二、部分字段命名约定为了满足程序处理需要,先约定好某些字段的命名、类型、名称,任何新增表中字段如含义和约定好的字段一致或相近,需要遵循本约定。
每次同步后,同步管理表中的Last_Ver需要进行自增。
新增(删、改)系统数据、基础数据、业务数据中对应得Last_Ver需要参照同步管理表中的Last_Ver,让两者保持相等。
同步时,增量同步那些Last_Ver和同步管理表中的Last_Ver一样的数据。
Lastest_Op_Date用来处理业务逻辑同步的行级锁字段,每次业务操作均进行更新,更新为当前系统时间。
Lastest_Op_User记录每次业务操作对应的操作用户。
Lastest_Op_Type用来标定最后操作类型。
Create_Date和Create_User用来记录当前数据的原始创建时间和创建人。
如果Create_Date和Lastest_Op_Date等字段同时存在于数据中,则初始建立数据时候需要同时给这些字段赋值,并保持Create_Date 等于Lastest_Op_Date,Create_User等于Laster_Op_User。
数据库表设计中的字段命名规范与约定

数据库表设计中的字段命名规范与约定在数据库设计中,字段命名是一个重要的环节,它直接关系到数据库的可读性和可维护性。
良好的字段命名规范和约定可以提高团队合作的效率,减少沟通和理解方面的困扰。
本文将介绍一些常用的字段命名规范和约定,帮助开发者更好地进行数据库表设计。
一、命名规范1. 采用有意义的名称字段名称应该准确地描述其含义,命名应该具有可读性。
避免使用不清晰、模糊的缩写和简写。
比如,使用"age"代表"年龄",而不是"a"或"ag"。
2. 使用小写字母字段名称一般应该使用小写字母,这样可以增加可读性。
同时,使用小写字母可以保证跨平台的兼容性,因为不同的数据库管理系统可能会对大小写敏感。
3. 使用下划线分隔单词单词间最好使用下划线进行分隔,这样可以增加字段名称的可读性。
比如,使用"first_name"代表"名字",而不是"firstname"或"FirstName"。
4. 避免使用保留字和关键字字段名称中应该避免使用数据库管理系统所规定的保留字和关键字,否则可能会导致语法错误。
可以在命名之前查阅相关数据库管理系统的官方文档以避免此类问题。
5. 避免过长的字段名称字段名称过长会增加阅读的难度,而且在编程时也可能限制命名的长度。
建议字段名称控制在30个字符以内,既可以保证可读性,又可以避免编程限制。
二、常见字段命名约定1. 主键字段命名主键字段命名应该易于理解和识别,一般采用表名加上"ID"的方式进行命名。
比如,对于名为"用户"的表,主键字段可以命名为"user_id"。
2. 外键字段命名外键字段命名应该与所关联的主键字段名称保持一致,这样可以减少混淆。
可以在所关联的主键字段名称后加上"_id"进行命名。
fastadmin 数据库表字段命名规则

fastadmin 数据库表字段命名规则FastAdmin是一个基于ThinkPHP5+Bootstrap开发的一款快速开发的后台管理系统,其中的数据库表字段命名规则是非常重要的,它直接影响到系统的运行和维护。
下面介绍一下FastAdmin中的数据库表字段命名规则。
一、字段命名规范1. 表名命名规则:表名应该使用小写字母,并使用下划线分隔单词。
例如,用户表可以命名为user。
2. 字段名命名规则:字段名也应该使用小写字母,并使用下划线分隔单词。
例如,用户的姓名字段可以命名为username。
3. 主键命名规则:主键字段应该以表名作为前缀,加上_id后缀。
例如,用户表的主键可以命名为user_id。
4. 外键命名规则:外键字段应该以被关联表名作为前缀,加上_id 后缀。
例如,用户表关联角色表的外键可以命名为role_id。
5. 唯一索引命名规则:唯一索引字段应该以表名作为前缀,加上唯一性约束的字段名。
例如,用户表的唯一索引字段可以命名为user_username_unique。
6. 普通索引命名规则:普通索引字段应该以表名作为前缀,加上索引的字段名。
例如,用户表的普通索引字段可以命名为user_username_index。
7. 默认值命名规则:默认值字段应该以表名作为前缀,加上默认值的字段名。
例如,用户表的默认值字段可以命名为user_status_default。
8. 外键约束命名规则:外键约束应该以表名作为前缀,加上外键字段名和被关联表名。
例如,用户表关联角色表的外键约束可以命名为user_role_fk。
二、命名规范的作用1. 提高代码的可读性:遵循命名规范可以让代码更易于理解和维护,减少了开发人员对字段含义的猜测。
2. 提高数据库性能:良好的命名规范可以帮助数据库优化器更好地利用索引,提高查询效率。
3. 方便系统集成:遵循统一的命名规范可以方便不同系统之间的集成和数据交换。
4. 方便系统迁移:遵循命名规范可以减少系统迁移时的字段映射和转换工作。
数据库命名规范(表、字段名)

数据库命名规范(表、字段名)一.实体和属性的命名1.常用单词已经进行了缩写,在命名过程当中,根据语义拼凑缩写即可。
注意,由于ORCAL 数据库会将字段名称统一成大写或者小写中的一种,所以要求加上下划线举例:定义的缩写 Sales: Sal 销售;Order: Ord 订单;Detail: Dtl 明细;则销售订单名细表命名为:Sal_Ord_Dtl;2.如果表或者是字段的名称仅有一个单词,那么建议不使用缩写,而是用完整的单词。
举例:定义的缩写 Material Ma 物品;物品表名为:Material, 而不是 Ma.但是字段物品编码则是:Ma_ID;而不是Material_ID3.所有的存储值列表的表前面加上前缀Z目的是将这些值列表类排序在数据库最后。
4.所有的冗余类的命名(主要是累计表)前面加上前缀X冗余类是为了提高数据库效率,非规范化数据库的时候加入的字段。
或者表5.关联类通过用下划线连接两个基本类之后,再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
关联表用于保存多对多关系。
如果被关联的表名大于10个字母,必须将原来的表名的进行缩写。
如果没有其他原因,建议都使用缩写。
举例:表Object与自身存在多对多的关系,则保存多对多关系的表命名为:R_Object;表 Depart和Employee;存在多对多的关系;则关联表命名为R_Dept_Emp6.每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自动生成的编码,统一命名为:ID;如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名。
举例:销售订单的编号字段命名:Sal_Ord_ID;如果还存在一个数据库生成的自动编号,则命名为:ID。
7.所有的属性加上有关类型的后缀,类型后缀的缩写定义见文件《类型后缀缩写定义》,注意,如果还需要其它的后缀,都放在类型后缀之前。
二.关系的命名关系的命名基本上按照;如有特殊情况,可以灵活处理.[must/may/can/should][verb/verb+prep][a/many/exatly num][or a/many]的结构命名三.域的命名四.触发器的命名五.有关于默认的几点说明1.严格依赖关系的主细表,主表的后缀Main可以不写。
数据库字段命名规则

数据库字段命名规则
以内
1.简洁易懂:尽量采用有意义的英文名称,更利于快速理解,而不是英文的拼音、容易困惑的简写等;
2.规范约束:遵守一定的命名规范,保证相同规范下的有效性,例如大写规则,全大写(ALL_UPPER_CASE),驼峰命名(camelCase)等,它们能够减少错误;
3.分段分词:多个构成,如用下划线分隔,比如有USER_ID(用户ID)、USER_NAME (用户名称),而不是像userid,usename;
4.避免冲突:与关键字以及或系统函数等冲突,如order(订单),desc(降序排列),len(长度)等;
5.节省符号:比如姓名name,而不宜命名为na_me,者密码password,而不应该写成pwd,给人造成混乱;
6.不用复数或单数:不要把名称写成英文的复数形式,如user在表的命名中也不要写成users,这样会让人误解;
7.中文命名:当有多好的表达意思再采用中文名称来命名数据库字段,比如订单编号使用ORDER_NO将变得更加清晰易懂。
表、字段命名规范

命名设计规范1 规范说明规范是一系列标准,规定数据仓库的表设计、字段命名,数据类型、字段长度、界面要求等。
范围:项目过程中的工作内容要求:所有项目组成员都要严格遵守目的:统一项目组行为,统一项目产品规格内容:一系列规则,包括:设计规范、命名规范、界面规范等2 设计规范2.1 命名规范命名规则约束的范围包括:数据库的命名、表的命名及字段的命名。
数据库相关的命名规则采用与通常的编程的变量命名规则原则一致,具体要求如下:1)字段名及表名为典型的名词结构;2)中文名称要求语言精炼、文法严谨;3)望文知意、易懂易用,禁止采用如:A002这种命名;4)主体上采用拼音字母的首写字母拼写构成,基于惯常用法可适度采用无词义歧义性的英文命名;5)长度不少于3个字母,不大于12个字母;6)在对于拼音首字母类似的字段和表,为区别,添加下划线和数字如男性人数:NXRS,女性人数:NXRS_2。
2.2 数据表及字段规范表及字段的设计描述要求:表4-1 表及字段规范示例说明:键中P[rimary]指主键,F[oreign]指外键。
这里的外键是逻辑的外键,主要用来阐述数据表间关系,可能物理上未必建立外键,但是如果数据是表引用关系也算。
外键的字段在描述中必须指明哪个表哪个字段。
Char(18):指18位定长字符串。
Number(18,4):指18位数字,其中小数点后有4位。
2.3 数据类型规范在表的数据类型描述中,采用以下的常用数据类型进行描述,后面是与Oracle、SQL Server和Access的类型对照。
表4-2 数据类型规范表注:原则上只使用这6种基本类型,不推荐使用Bool类型,请用int代替。
●界面展现规范✓界面风格要一致例如:统一的色调、统一的字体字号✓特定内容的展现格式要一致例如:日期的格式、数字的格式●交互方式的规范✓操作风格要一致例如:“*”表示必输项。
数据库字段命名规则

数据库字段命名规则数据库字段命名是计算机编程过程中一个非常重要的步骤,有助于更好地掌握和控制程序的运行细节。
给出有效、正确的字段命名规则,是正确设计数据库结构的关键步骤,并且是规范开发的基础,提高开发的效率、准确率和可维护性。
1.名简单易懂:字段的命名应该能够简洁明了地描述其存储的信息,避免使用不可理解的简写,比如A1、A2;2. 不要使用SQL保留字:SQL具有一定的保留字,如Update、Select、Create等,作为字段名比较容易引起歧义,因此,在命名字段时不要使用SQL保留字;3.段命名应该描述具体:字段名称只表明属性,而不仅仅表达一个概念,比如studentName而不是name;4.名应避免过长:为了避免命名过长,可以采用取一个缩写或者去掉一些不容易理解的字;5.名应该一致:统一的命名规则,可以减少费尽心机地建立合理字段,让程序员更容易拿到的数据;6. 使用缩写时应注意:在使用缩写时要把完整的单词拼成一个缩写,比如Name可以写成Nm,而不是Nam;7.量少用数字:使用数字可能导致记忆困难,不利于程序员阅读程序,最好使用文字;8.名应该唯一可识别:尽量使用不那么常见的单词作为字段名,以使之唯一区分,增加程序的可读性;9.名应该能减少重复性工作:尽量使用一些比较容易记忆的词句作为字段名,以减少重复的工作和维护的工作量;10.可能使用标准的单词和规范的书写:只有使用具有完整含义的单词和符合标准的书写形式,才能让其它程序员阅读,理解这份代码;通过认真针对数据库字段命名,可以减少程序代码阅读难度,提高代码可读性,同时也有利于程序员开发和维护的效率,使得程序的可维护性和可扩展性得到提高。
数据库表的结构设计中,和命名字段相关的重要性已经被证明过,从而有助于改善数据库使用及开发效率。
此外,命名规范也能够提高查询速度,使数据库更加安全、可靠。
在日常开发中,应该充分重视数据库字段命名,根据不同的项目设计不同的字段命名规范,以更好保障数据库安全、可维护性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据库表字段命名规范
摘要:当前研发工作中经常出现因数据库表、数据库表字段格式不规则而影响开发进度的问题,在后续开发使用原来数据库表时,也会因为数据库表的可读性不够高,表字段规则不统一,造成数据查询,数据使用效率低的问题,所以有必要整理出一套合适的数据库表字段命名规范来解决优化这些问题。
本文是一篇包含了数据库命名、数据库表命名、数据库表字段命名及SQL语言编码的规范文档,针对研发中易产生的问题和常见错误做了一个整理和修改,为日后涉及到数据库相关的研发工作做好准备。
一、数据库命名规范
采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔,一个项目一个数据库,多个项目慎用同一个数据库
二、数据库表命名规范
数据表命名规范
(1)采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔
(2)全部小写命名,禁止出现大写
(3)禁止使用数据库关键字,如:name,time ,datetime,password等(4)表名称不应该取得太长(一般不超过三个英文单词)
(5)表的名称一般使用名词或者动宾短语
(6)用单数形式表示名称,例如,使用 employee,而不是 employees
明细表的名称为:主表的名称+字符dtl(detail缩写)
例如:采购定单的名称为:po_order,则采购定单的明细表为:po_orderdtl (7)表必须填写描述信息(使用SQL语句建表时)
命名规范
①模块_+功能点示例:alllive_log alllive_category
②功能点示例:live message
③通用表示例:all_user
待优化命名示例
①冗余:
错误示例: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
说明:去除项目名,统一命名规则,动宾短语分离且动宾逻辑顺序统一
三、数据库字段命名规范
字段命名规范
(1)采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔
(2)全部小写命名,禁止出现大写
(3)字段必须填写描述信息
(4)禁止使用数据库关键字,如:name,time ,datetime password?等(5)字段名称一般采用名词或动宾短语
(6)采用字段的名称必须是易于理解,一般不超过三个英文单词
(7)在命名表的列时,不要重复表的名称
例如,在名employe的表中避免使用名为employee_lastname的字段
(8)不要在列的名称中包含数据类型
(9)字段命名使用完整名称,禁止缩写
命名规范
①名词示例:user_id user_name sex
②动宾短语示例:is_friend is_good
待优化命名示例
①大小写规则不统一
错误示例: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”
字段类型规范
(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字段)
数据库中每个字段的规范描述?
(1)尽量遵守第三范式的标准(3NF)?
表内的每一个值只能被表达一次?
表内的每一行都应当被唯一的标示?
表内不应该存储依赖于其他键的非键信息
(2)如果字段事实上是与其它表的关键字相关联而未设计为外键引用,需建索引
(3)如果字段与其它表的字段相关联,需建索引
(4)如果字段需做模糊查询之外的条件查询,需建索引
(5)除了主关键字允许建立簇索引外,其它字段所建索引必须为非簇索引
四、SQL语言编码规范?
大小写规范?
(1)所有关键字必须大写,如:INSERT、UPDATE、DELETE、SELECT及其子句,IF……ELSE、CASE、DECLARE等
(2)所有函数及其参数中除用户变量以外的部分必须大写
(3)在定义变量时用到的数据类型必须小写
注释?
注释可以包含在批处理中,在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可维护性,本规范建议:?
(1)注释以英文为主,实际应用中,发现以中文注释的SQL语句版本在英文环境中不可用,为避免后续版本执行过程中发生某些异常错误,建议使用英文注释
(2)注释尽可能详细、全面创建每一数据对象前,应具体描述该对象的功能和用途,传入参数的含义应该有所说明,如果取值范围确定,也应该一并说明,取值有特定含义的变量(如boolean类型变量),应给出每个值的含义(3)注释语法:单行注释、多行注释?
单行注释:注释前有两个连字符(--)对变量、条件子句可以采用该类注释多行注释:符号之间的内容为注释内容,对某项完整的操作建议使用该类注释
(4)注释简洁,同时应描述清晰
(5)函数注释:?
编写函数文本--如触发器、存储过程以及其他数据对象--时,必须为每个函数增加适当注释,该注释以多行注释为主,主要结构如下:?
CREATE?PROCEDURE?sp_xxx?。