范式

龙蜥社区开发者服务平台 devFree 致力于打造成业界最齐备的开发者自助服务体系，为开发者提供开源我的项目的全流程撑持！ 让开发更简略、更高效，Just show me the code！ 开发者服务平台 devFree MeetUp 由龙蜥社区基础设施 SIG 主办，本次流动邀请了阿里云、电子五所、浪潮信息、联通数科、统信软件、中科曙光、中科微澜及成都东软学院、中南大学等泛滥厂商及科研院所一起探讨面向未来的开发者服务新范式，正式公布“开发者服务平台 devFree2.0”和“龙蜥众测共创行动指南”，同时联结合作伙伴一起隆重举行社区众测共创启动典礼！ 欢送大家报名来加入此次 MeetUp，一起与资深技术大咖面对面探讨更简略、更高效的开发者服务平台。流动具体议程见下： 留神：扫描上方海报中转报名界面，来现场参会、体验 demo 的小伙伴将会取得社区精美礼品一份～ ——完—— 为给大家提供更好的内容和服务，龙蜥社区诚挚地邀请大家参加问卷调研，请扫描下方二维码或点此链接填写，咱们将筛选出优质反馈，送出龙蜥周边！

关系表设计正当与否是影响关系型数据库性能的外围因素之一。 谈到关系型数据库表设计问题，首先想到的是范式实践。也就是说一张表的设计首先要满足肯定的范式，完了后再依据肯定的需要来反范式设计，也即冗余备用设计。 数据库范式个别蕴含6个，别离为1NF、2NF、3NF、BCNF、4NF、5NF。 这6个范式级别别离从数据是否容许肯定范畴的冗余、数据是否更加精细化的治理这两个关键点登程，越往后，数据越标准，冗余越小，可读性越强。 一般来说，达到3NF或者BCNF即可，或者更进一步，达到4NF即可，5NF更加偏差学术。 再次假如咱们对各种依赖关系十分明确（局部函数依赖，齐全函数依赖，传递函数依赖，多值依赖，连贯依赖等）。上面我用经典的员工表与学生表来举例说明每个范式的逐级优化。 1NF： 也即属性具备原子性，不可拆分。对数据如何寄存要求最低，目标是让关系表的属性（字段或列）放弃原子性，不可再次拆分。1NF 用员工表来做示例，表构造如下： (debian-ytt1:3500)|(ytt)>desc employee;+-----------------+-------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-----------------+-------------+------+-----+---------+-------+| employee_number | varchar(64) | YES | | NULL | || employee_name | varchar(64) | YES | | NULL | || salary | json | YES | | NULL | || dept | varchar(64) | YES | | NULL | || dept_desc | text | YES | | NULL | |+-----------------+-------------+------+-----+---------+-------+5 rows in set (0.00 sec)表 employee 有五个字段，别离为 employee_number(员工号码)、employee_name(员工姓名)、salary(员工薪水)、dept(所属部门）、dept_desc(所属部门形容信息）。 ...

Normalization/Denormalization范式化设计Normalization 概念设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。 Normalization 优点节省存储空间，并减少不必要的更新Normalization 缺点查询缓慢：⼀个完全范式化设计的数据库会经常⾯面临“查询缓慢”的问题，因为数据库越范式化，就需要 Join 越多的表几种范式第一范式：1NF（First Normal Form）消除非主属性对键的部分函数依赖 第二范式：2NF（Second Normal Form）消除非主要属性对键的传递函数依赖 第三范式：3NF（Third Normal Form）消除主属性对键的传递函数依赖 BC范式：BCNF（Boyce-Codd Normal Form）主属性不依赖于主属性 反范式化设计Denormalization 概念数据 “Flattening”，不使用关联关系，⽽而是在文档中保存冗余的数据拷贝 Denormalization 优点读取性能好，查询快，无需 join 操作Denormalization 缺点浪费空间一条数据的改动，可能会引起很多数据的更新小结关系型数据库一般优先考虑范式化设计非关系型数据库一般优先考虑反范式化设计范式化设计节省了存储空间，但是存储空间却越来越便宜；范式化简化了更新，但是数据“读”取操作可能更多反范式化设计数据库会通过压缩尽量减少空间占用，如 Elasticsearch 通过压缩 _source 字段，减少磁盘空间的开销数据库事务事务的概念数据库事务（Database Transaction，简称“事务”）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。这个过程中的所有操作要么都成功，要么都不成功。 ACIDACID 是事务的四个特性，指的是atomicity，原子性；consistency，一致性；isolation，隔离性；durability，持久性。 原子性（Atomicity）指所有在事务中的操作要么都成功，要么都不成功，所有的操作都不可分割，没有中间状态。一旦某一步执行失败，就会全部回滚到初始状态。 一致性（Consistency）指的是逻辑上的一致性，即所有操作是符合现实当中的期望的。具体参考下一节 隔离性（Isolation）即不同事务之间的相互影响和隔离的程度。比如，不同的隔离级别，事务的并发程度也不同，最强的隔离状态是所有的事务都是串行化的（serializable）（即一个事务完成之后才能进行下一个事务），这样并发性也会降到最低，在保证了强一致性的情况下，性能也会受很大影响，所以在实际工程当中，往往会折中一下。 持久性（Durability）可以简单地理解为事务执行完毕后数据不可逆并持久化存储于存储系统当中 CAPCAP 理论主要是针对分布式存储系统的，C 是指 Consistency 一致性，A 是指 Availability 可用性，P 是指Partition tolerance 分区容忍性。CAP 定理认为分布式系统中这三个特性最多只能同时满足两个特性。 一致性（Consistency）指在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（Availability）在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） 分区容忍性（Partition tolerance）即当节点之间无法正常通信时，就产生了分区，而分区产生后，依然能够保证服务可用，那么我们就说系统是分区容忍的。显然如果节点越多，且备份越多，分区容忍度就越高（因为即便是其中一个或多个节点挂了，仍然有其它节点和备份可用）。 理解一致性（此 C 非 彼 C）实际上我们通常说的数据库事务的一致性和分布式系统的一致性并不是一个概念。这里可以区分成“内部一致性”和“外部一致性”。“内部一致性”搞数据库的人很少这么说，一般就直接说一致性，更准确的说是“Consistency in ACID”（“事务 ACID 属性中的一致性”）；“外部一致性”是针对分布式系统而言的，分布式领域提及的 Consistency 表示系统的正确性模型，著名的也是臭名昭著的 CAP 理论中的 C 就是这个范畴的。这主要是由于分布式系统写入和读取都可能不在同一台机器上，而这必然会有一段时间导致不同机器上所存的数据不一致的情况，这就是所谓的“不一致时间窗口”。 ...

良好的逻辑设计与物理设计是高性能的基石，当我们在设计数据表结构的时候，应该跟根据业务逻辑来分析具体情况，然后设计出比较合理，高效的数据表结构在数据表结构设计中，不得不提的就是范式与数据类型了 Mysql三范式字段不可分；即字段具有原子性 字段不可再分,否则就不是关系数据库;有主键，非主键字段依赖主键; 唯一性 一个表只说明一个事物非主键字段不能相互依赖；每列都与主键有直接关系，不存在传递依赖范式的优点与缺点优点 范式化设计更新通常比反范式化更新要快当数据高度范式化时，就只有少量或者没有重复数据，这样修改的时候就只需要修改少量的数据范式化的表通常比较小，可以更好的放在内存里面，操作就会更容易因为范式化设计之后，冗余数据较少，所以在执行某些查询的时候可能就不会用到group by，distinct 这样也提高了查询效率缺点因为严格遵循范式化设计的话。在某些业务场景下可能会查询多个表。这样的同样会使得查询效率变的很低。而且在某些时候因为多表查询的原因，可能某些索引不会被命中。这里我们看到范式化的设计有优点也有缺点，所以在实际的项目中，我们通常是混范式化设计。某些表完全遵循范式化；某些表遵循部分范式化设计。在设计某些表的时候 会用到反范式化的思想，将某些数据存到同一张表中。这样可以减少很多关联查询，也可以更好的去设计索引关系。 比如users表 与 user_messages表中，都会保存一个user_account_type字段。这样的话，在单独查询user_account_type=1的消息总数时就不需要再去关联users表了。数据类型Mysql支持的数据类型有很多种，所以选择正确的数据类型对提高性能有着至关重要的作用。但是不管哪种数据类型我们都应该参考下面几个原则 更小的通常更好；更小的数据类型通常更快，因为他们占用更少的磁盘、内存、CPU缓存。简单就好；操作简单的数据类型通常需要更少的CPU周期。例如：整型比字符串操作代价更低尽量避免NULL；如果查询中包含可为Null的列，对于Mysql来说更难优化，因为可以为null的列使得索引，索引统计和值都变的更加复杂整数类型Mysql的整数类型有 TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT。他们使用到的储存空间分别是,8,16,24,32,64位。值的范围是-2(N-1)到2(N-1)-1整形可以选择UNSIGNED属性，表示是否有符号，不允许为负值。如 TINYINT UNSIGNED 值的范围 0~255， 而 TINYINT 值的范围是-128-127。需要注意点是有符号跟无符号使用相同的储存空间，拥有相同的性能，所以可以根据实际情况来选择类型。 字符串类型VARCHAR,CHAR是两种最主要的字符串类型， VARCHAR类型用于储存可变字符串，是常见的字符串类型。它比定长类型更节省空间。CHAR定长字符串类型，分配固定长度的空间。在保存某些定长字符串时比VARCHAR更有优势、比如md5定长字符串，因为定长类型字符串不容易产生碎片。对于VARCHAR(5)和VARCHAR(100)储存hello的空间开销是一样的，那么是不是我们就可以定义长度为100呢?当然不是了，更长的列会消耗更多的内存，因为Mysql通常会分配固定大小的内存块来保存内部值。所以最好的策略就是分配合理的长度，这样就分配到真正需要的 空间。日期，时间类型DATETIME类型，能够保存1001-9999年，精度为秒，与时区无关。TIMESTAMP类型，保存了从1970-01-01午夜到现在的秒数，只使用了4个字节，只能表示1970-2038年。TIMESTAMP依赖于时区。TIMESTAMP在默认情况下，如果没有指定列的值，会把列的值设置为当前时间，在更新的时候也可以更新列的值为当前时间。通常情况下应该尽量使用TIMESTAMP,因为它比DATETIME空间效率更高，有时候我们会将Unix时间戳保存为整数值以表示当前时间，实际上并不会带来任何收益。 上面列举了几个常用的mysql类型，在实际使用中可以根据业务选择最优的方案。一般情况下遵循 更小的通常更好,简单就好 ,尽量避免NULL是没有问题的。关于mysql的数据类型选择，就写到这里。后面也会写一些关于索引优化方面的文章，如果问题欢迎大家指出。

亲爱的盆友们又是新的一年，你，准备好新的学习计划了吗？是读书100本，还是考上5个证？嘛不管怎么说，角落里那一堆蒙尘的计划表好像在昭示着这仍然是一个充满朝气又艰难的9102年呢！总之，先把#技本功#进修班报了再说吧何以暴富，唯有学习！-2019年第3期-夫子说数据库的库表设计是数据库开发阶段的基础，合理的结构和关系将会大大提升以后数据库的运行性能；而表设计要遵循范式规则，除了比较常见和通用的三大范式外，还有BCNF、4NF、5NF…甚至更高的范式，但是也不是范式越高越好，有时候也需要逆范式化设计表。今天，就重点讲一讲解析范式（1NF-4NF）。1NF 1、1NF的定义关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同的范式。满足最低要求是第一范式(1NF)，1NF的定义如下：1NF：关系中的每一个分量必须是一个不可分的数据项。通俗地说，第一范式就是表中不允许有小表的存在。比如，对于如下的员工表，就不属于第一范式：上表中，出现了属性薪资又被分为基本工资和补贴两个子属性，就好像表中又分割了一个小表，这就不属于第一范式。如果将基本工资和补贴合并，那么该表符合1NF。2、1NF存在的问题1NF是最低一级的范式，范式程度不高，存在很多的问题。比如用一个单一的关系模式学生来描述学校的教务系统：学生(学号,学生姓名,所在系,系主任姓名,课程号,成绩)学生表假如选定学号为主键，这个表满足第一范式，但是存在如下问题：● 数据冗余：一个系有很多的学生，同一个系的学生的系主任是相同的，所以系主任名会重复出现。● 更新复杂：当一个系换了一个系主任后，对应的这个表必须修改与该系学生有关的每个元组。● 插入异常：如果一个系刚成立，没有任何学生，那么这个无法把这个系的信息插入表中。● 删除异常：如果一个系的学生都毕业了，那么在删除该系学生信息时，这个系的信息也丢了。2NF 1、2NF的定义2NF的定义：如果关系R属于1NF，且每一个非主属性完全函数依赖于任何一个候选码，则R属于2NF。通俗地说，2NF就是在1NF的基础上，表中的每一个非主属性不会依赖复合主键中的某一个列。按照定义，上面的学生表就不满足2NF，因为学号不能完全确定课程号和成绩(每个学生可以选多门课)。将学生表分解为：学生(学号,学生姓名,系编号)，系(系编号,系名,系主任)，选课(学号,课程号,成绩)。每张表均属于2NF。新定义一张表：销售表(产品id,地区id,价格,产品名)，同一个产品在不同地区价格不同。这个表就不属于2NF，因为非主属性产品名不是完全函数依赖于主键，而是完全依赖于产品id，即表中存在非主属性对主键的部分依赖。将销售表分解：产品(产品id,产品名)，销售表(产品id,地区id,价格)。每张表均属于2NF。2、2NF存在的问题下面举例说明2NF存在的相应问题。对于公司里的员工管理，每个员工只能属于一个部门，每个部门可以有多个员工，定义如下关系模式：员工管理表(员工id,员工名,所属部门id,部门经理);对应的表：在的问题：● 删除异常：如果某个部门的人都跳槽了，那么在删除这些员工的同时也丢失了这个部门的信息。● 修改复杂：如果一个员工换了一个部门，不但要修改所属部门，还要修改部门经理这个属性列。● 插入异常：如果公司新成立了一个部门，但是目前没有招收员工，那么这个部门信息也无法插入到这个表中，因为没有主键。3NF 1、3NF的定义3NF的严格定义如下：关系模式R属于1NF，若R中不存在这样的码X，属性组Y及非主属性Z，使得X函数确定Y、Y函数确定Z成立，Y不能函数确定X，则称R是属于3范式的。通俗地说，就是在满足1NF的基础上，表中不存在非主属性对码的传递依赖。也就是说表中非主属性不会间接地依赖于码。如上面的员工管理表就不属于3NF，因为非主属性部门经理依赖于所属部门，所属部门依赖于员工id，即部门经理传递依赖于员工id。将员工管理表分解：员工管理(员工id,员工名,部门名)，部门(部门名,部门经理)。则每张表均属于3NF。2、3NF存在的问题现在有这样的一个场景：对于一个工程(ENO)的实施，每个工程需要多个零件，每个供应商(SNO)只生产一个零件(PNO)且受工厂规模所限只能同时供应一个工程，每个工程使用的同一个零件都来自同一个生产商。定义关系模式：SPE(SNO,PNO,ENO)。表中存在如下函数依赖：(ENO,PNO)→SNO(ENO,SNO)→PNOSNO→PNOSPE是属于3NF的，因为根据定义，表中不存在非主属性对码的传递依赖和部分依赖。但是这张表存在如下的问题：● 插入异常：如果有一个新的工厂建立了，但是这家工厂还没有接到任何订单，那么无法将这个工厂信息插入到SPE中，因为缺少了主属性ENO。● 删除异常：如果某个供应商只给一个工程提供零件，现在这个工程不再需要这个零件了。那么PNO就要删除，而PNO是主属性，整个元组都被删除了，这样就丢失了一个供应商信息。BCNF 1、BCNF的定义BCNF比3NF更进一步，可以认为是扩充的3NF，其定义如下：关系模式R属于1NF，若X函数确定Y(且X不包含Y)时X必含有码，则R属于BCNF。翻译成人话，就是在第一范式的基础上，若关系R中的每一个决定因素都必含有码，则关系R属于BCNF。很显然，上面的SPE表不属于BCNF，因为SPE中存在一个决定因素SNO，SNO不含有码。将SPE表分解：SP(SNO,PNO)，SE(SNO,ENO)。则每张表均属于BCNF。2、BCNF存在的问题仍以上面的工程实施场景为例：假设每个供应商可以生产多个零件，可以供应给多个工程，一个工程需要多个零件，但同一个工程的同一个零件必须来自同一个供应商。那么关系SPE(SNO,PNO,ENO)对应的表数据可能是如下：此时表SPE存在如下的函数依赖：(PNO,ENO)→SNO根据BCNF的定义，此时表SPE属于BCNF。但是这样的关系模式仍具有不好的地方：数据冗余度太大。假如供应商S3生产了n个零件，每个零件供应给m个工程，那么显然S3要在表中重复m*n次。4NF 1、4NF的定义4NF严格定义如下：关系模式R属于1NF，对于R中的每一个非平凡多值依赖X→→Y(X不包含Y)，X都含有码，则R属于4NF。通俗地说，对于有三个属性的表，给定属性A一个值，剩余两个列之间不存在多对多的关系。例如，在上面的SPE表中，给定SNO=S1，PNO和ENO之间很明显存在多对多的关系，故上表是不属于4NF的。根据4NF的定义可知，4NF所允许的非平凡的多值依赖实际上就是函数依赖，4NF就是消除表中的非平凡多值依赖关系。2、4NF存在的问题一般地，4NF属于规范程度比较高的范式了。但是考虑到连接依赖的话，4NF中也仍存在数据冗余，插入、修改、删除异常等问题。如果消除了4NF中的连接依赖，则达到了5NF的关系模式；5NF范式化已经很高了，实际工作中很少会遇到这么高的范式表，这里就不再叙述了。范式的相关总结如果只考虑函数依赖，那么BCNF范式最彻底，已消除插入和删除的异常。而3NF的不彻底性表现在表中可能存在主属性对码的部分依赖和传递依赖。如果考虑到多值依赖，那么4NF范式是规范程度最高的。但4NF中可能存在连接依赖的关系，而5NF可以消除连接依赖。在数据库中，有时并不是规范化程度越高越好，有时候也需要逆范式化设计表。因为范式越高，产生的表就越多，一个简单的查询需求就可能涉及到多张表的关联，影响查询效率。一般地，数据库中的表都在3NF。