2023年7月27日发(作者:)
⼀、数据库表设计规范⼀、三范式为了建⽴冗余较⼩、结构合理的数据库,设计数据库时必须遵循⼀定的规则。在关系型数据库中这种规则就称为范式。范式是符合某⼀种设计要求的总结。要想设计⼀个结构合理的关系型数据库,必须满⾜⼀定的范式。1.第⼀范式确保每列保持原⼦性列不可分有主键根据实际需求来定。⽐如某些数据库系统中需要⽤到“地址”这个属性,本来直接将“地址”属性设计成⼀个数据库表的字段就⾏。但是如果系统经常会访问“地址”属性中的“城市”部分,那么就⾮要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进⾏存储,这样在对地址中某⼀部分操作的时候将⾮常⽅便。这样设计才算满⾜了数据库的第⼀范式,如下表所⽰。
2.第⼆范式确保表中的每列都和主键相关每个表只描述⼀件事主要针对联合主键⽽⾔,不存在部分依赖,每⼀列都跟联合主键有关系,⽽与联合主键中的其中⼀个键⽆关系⽐如要设计⼀个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所⽰。这样就产⽣⼀个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的联合主键相关,⽽仅仅是与商品编号相关。所以在这⾥违反了第⼆范式的设计原则。⽽如果把这个订单信息表进⾏拆分,把商品信息分离到另⼀个表中,把订单项⽬表也分离到另⼀个表中,就⾮常完美了。如下所⽰。
这样设计,在很⼤程度上减⼩了数据库的冗余。如果要获取订单的商品信息,使⽤商品编号到商品信息表中查询即可。
3.第三范式确保每列都和主键列直接相关,⽽不是间接相关,不存在传递依赖。第三范式需要确保数据表中的,每⼀列数据都和主键直接相关,⽽不能间接相关解决间接相关,把不直接相关的再建⼀张表,采⽤外键形式将两张表关联.⽐如在设计⼀个订单数据表的时候,可以将客户编号作为⼀个外键和订单表建⽴相应的关系。⽽不可以在订单表中添加关于客户其它信息(⽐如姓名、所属公司等)的字段,因为添加后就会出现传递依赖 :订单编号--》客户编号, 客户编号--》客户详细信息
如下⾯这两个表所⽰的设计就是⼀个满⾜第三范式的数据库表。这样在查询订单信息的时候,就可以使⽤客户编号来引⽤客户信息表中的记录,也不必在订单信息表中多次输⼊客户信息的内容,减⼩了数据冗余。
⼆、数据库表设计规范1.表与字段的规范(1)表达是与否概念的字段,必须使⽤ is _ xxx 的⽅式命名,数据类型是 unsigned tinyint( 1 表⽰是,0 表⽰否 ) 。说明:任何字段如果为⾮负数,必须是 unsigned 。正例:表达逻辑删除的字段名 is_deleted ,1 表⽰删除,0 表⽰未删除。
(2)表名、字段名必须使⽤⼩写字母或数字并以下划线分隔 , 禁⽌出现数字开头,禁⽌两个下划线中间只出现数字,名字要做到见名思意,不要超过32个字符。说明:MySQL 在 Windows 下不区分⼤⼩写,但在 Linux 下默认是区分⼤⼩写。正例: aliyun _ admin , rdc _ config , level 3_ name反例: AliyunAdmin , rdcConfig , level _3_ name
(3)⼩数类型为 decimal ,禁⽌使⽤ float 和 double 。说明: float 和 double 在存储的时候,存在精度损失的问题,很可能在值的⽐较时,得到不正确的结果。如果存储的数据范围超过decimal 的范围,建议将数据拆成整数和⼩数分开存储。
(4)表必备三字段: id 主键, gmt _ create创建时间 , gmt _ modified更新时间 。
(5)不同表之间存储相同数据的列名和列类型必须⼀致(关联列)
(6)优先选择符合存储需要的最⼩、最简单的数据类型。选择数据类型只要遵循⼩⽽简单的原则就好,越⼩的数据类型通常会更快,占⽤更少的磁盘、内存,处理时需要的CPU周期也更少。越简单的数据类型在计算时需要更少的CPU周期,⽐如,整型就⽐字符操作代价低,因⽽会使⽤整型来存储ip地址,使⽤DATETIME来存储时间,⽽不是使⽤字符串。①尽量使⽤数字型字段 若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个⽐较字符串中每⼀个字符,⽽对于数字型⽽⾔只需要⽐较⼀次就够了。
②尽量使⽤位数较少的类型 ,⽐如能使⽤TINYINT/SMALLINT就不使⽤int,能使⽤⽆符号位就不适⽤有符号数据类型
③尽可能的使⽤ varchar/nvarchar 代替 char/nchar 因为⾸先变长字段存储空间⼩,可以节省存储空间,其次对于查询来说,在⼀个相对较⼩的字段内搜索效率显然要⾼些。只有在存储的字符串长度⼏乎相等,使⽤ char 定长字符串类型。
(7)不得使⽤外键与级联,⼀切外键概念必须在应⽤层解决。
(8)表和字段名要加注释 (9)将字段很多的表分解成多个表将使⽤频率低的字段拿出来新建⼀个表,完成分表,从⽽提⾼效率
(10)增加冗余字段适当的不遵循范式的要求,对于经查查询的外表字段可以在本表中增加冗余字段。⽐如经常要查⼀个学⽣的系名,就可以在学⽣表加⼀个系名的字段
2.索引规范(1)业务上具有唯⼀特性的字段,即使是多个字段的组合,也必须建成唯⼀索引。说明:不要以为唯⼀索引影响了 insert 速度,这个速度损耗可以忽略,但提⾼查找速度是明显的 。
(2)主键索引名为 pk_ 字段名;唯⼀索引名为 uk _字段名 ; 普通索引名则为 idx _字段名。
(3)在 varchar 字段上建⽴索引时,必须指定索引长度,没必要对全字段建⽴索引,根据实际⽂本区分度决定索引长度即可。
(4)限制每张表的索引数量,建议每张表的索引数量不超过5个,并且针对复合索引,最常⽤的、区分度最⾼的(列中不同值数量/列的总⾏数)、字段长度⼩的放到最左侧
(5)索引列定义为 not null索引null列需要额外空间保存,需要占⽤更多地空间,运算和⽐较的时候会占⽤更多的空间
(6)值分布稀少的字段不适合建⽴索引,⽐如性别
发布者:admin,转转请注明出处:http://www.yc00.com/web/1690433937a349238.html
评论列表(0条)