00:00
好,那么我们在讲完第一第二第三范式之后呢,咱们紧接着来讲一讲,这个叫反范式化啊前面呢,我们提到了,说这个范式的话呢,有这个优点,优点呢就是随着这个表呢,涉及的越多,越细致,这个冗余度呢就越低了,但是的话呢,就导致的问题呢,就是我们在查询的时候呢,可能这个效率呢反而是低了,诶OK,所以呢,我们在有些情况下呢,需要呢,用到这个叫反范式化的这个内容,来我们看下这个里边这个内容说有的时候呢,我们不能够简单的按照这个范式的规范呢去设计这个表。是吧,有的数据啊,看似冗余,但是对于我们这个业务来讲呢,还是非常重要的,那么这个时候的话呢,我们优先考虑的就是业务,所以呢,遵循的原则呢,叫业务优先的原则啊,在满足这个原则的情况下呢,我们再考虑呢,尽量的去减少这个冗余的事儿。啊,那什么叫业务优先的原则呢?我们举个例子,比如说呢,我们这个数据库当中,这个数据量呢比较大啊,系统的这个UV啊,PV啊,访问的频次啊也非常的高,那如果说呢,我们要是完全按照这个三范式去设计的话呢,就会导致了我们会产生大量的这种关联查询,然后这个时候呢,就会影响我们这个数据库的整体的性能,那此时的话呢,你就不能拘泥于我们说非要呢按照这个设施去设,呃这个范式呢去设计,那反而呢,使我们这个性能来降低以后,那用户的体验呢就很差了。
01:14
那这个时候呢,我们就考虑呢,诶,可以适当的增加一些冗余的字段啊,那么这个冗余的字段呢,其实就体现为呢,就属于我们这个反范式化的一种设计。所以说呢,我们要想提高呢,这个查询的一个效率呢,进行优化啊,反方式化呢,也属于其中的一个思路啊,OK,行,然后接着我们看看下边这个,呃,就是叫规范化和性能上的一个VS,就是有一定的这个矛盾的程度啊,要想达到一定的规范化,那性能的话呢,就有可能会受到影响。说为了满足某种商业的目的,数据库的性能呢,比规范化数据库啊更为重要。啊,在数据规范化的同时,综合要考虑数据库的一个性能,诶大家你想想是不是呢,这个也不仅局限在我们当前讲的这个知识层面,在实际生活当中,实际上呢,我们说这个规范化和这个所谓的一个性能呢,是不是也是一对矛盾的啊,你比如说在这个公司当中,大家呢,也通常发现呢,是不是这个公司越大啊,然后呢,这个规范的东西呢,就越多啊,因为你公司大了啊,然后呢,相互之间的话呢,你不能这个太随意了,所以我们就会出各种各样的规章制度和流程。
02:19
啊,尤其是这种大公司里边啊,这个这个规章制度和流程呢,是不是就特别的复杂是吧,那一旦这个规范化以后的话呢,反而使得呢,这个人跟人之间协作,我们去完成一件事情的时候呢,是不是这个性能反而会变低啊,啊原来的话呢,就可能喊一嗓子说老板这块我们这个事儿要做行不行啊行行就去了,那现在的话呢,你可能直接呢,需要写个邮件,邮件呢需要层层的审批,等审批下来以后呢,可能都半个月出去了。啊,那这个呢,就是性能呢,肯定会受到这个影响,对吧。啊,那么有一句呢,咱们老话呢讲叫什么叫水至清则无鱼。啊,大家想想这句话我觉得还是很有道理的啊,好,接着呃,那我们该如何去做呢?其实这块三个字呢,也提到了相关的一些这个手段啊,说呢,我们可以在给定的表中呢,去添加额外的字段以减少,那以大量的减少呢,需要从中搜索信息所需要的时间。
03:11
啊,相当于增加这个冗余字段,然后呢,通过在给定的表中啊,插入这个计算列,以方便的做查询。啊,这个呢,就是比如说我们在这个表当中,咱们呢,需要用到的是这个字段,这个字段这个呢,比如说是一个数量,这个呢是一个诶花的这个时间,然后呢,总时间是多少,需要这两个乘一下,对吧?那你要每次呢都需要呢,考虑这个总时间,你要是每次都现去算的话呢,这个量如果还挺大,这个花的时间就会多一些,那不妨呢,你这块呢,单独的定一个字段,把这两个的成绩呢,就直接呢记录在这儿,然后呢,每次查的时候呢,是不是直接查这个字段就可以了,不用呢线去计算啊,这呢也是能够节省我们的时间,按正样来讲的话呢,我们后边加的这个成积的字段应该是一个冗易字段了,对吧?啊不满足我们这个范式化的一个要求,但是这时候我们说加也是必要的。行,这呢就是泛泛的这样一讲,然后下边的话呢,我们来给大家举一个具体的例子。比如说我们提到这个员工表叫employees啊,部门表呢叫departments,咱们上的时候呢,主要呢,也就用到这两个表,对吧?那如果说呢,我们想查询这个员工的信息,比如说查询员工的ID啊,还有呢,这个员工他所在的部门的名称,诶,那么由于部门名称啊,是不是不存在我们员工表当中,所以我们是不是就进行了一个多表的一个联合查,这个联合查询对吧。
04:22
关联查询,然后呢,关联的条件呢,就是这个department ID,那这呢,你用到了两张表,那如果说呢,我们经常性的做这样的操作,而且呢,这个员工表中的这个员工数量还挺多,怎么办呢?我们可以考虑呢,在employees这个表中增加一个冗余的字段。啊,那么这个字段呢,叫做department name。啊,冗誉的字段啊,那么接下来的话呢,当你再经常性的做这样的一个查询操作的时候呢,我们就用不着呢,是不是这个关联查询了,你直接呢,用这个员工表就可以了,对吧,按理说的话呢,我们这样加了一个字段呢,是冗余的,实际上不满足我们这个是不是第三范式。啊,因为department ID呢,在我们员工表中,Department也在这个呢,他俩不是相互独立的对吧。
05:02
诶,但是呢,我们说呢,为了提升效率呢,就反反式化了啊,然后接着我们再看一下这个第二个例子,这呢就是我们上边讲的这个商品的这个信息啊,当时咱们讲的时候呢,说不满足这个三范式啊,因为呢,你这两个呢,它不是相互独立的对吧?我们把它呢,拆成了两个表啊,但是呢,如果说我们经常性的呢,查询某个商品它的这个类别名称啊,那这时候呢,我们呃还得进行这个关联查询不方便了,那怎么办呢?我们就诶在我们故这个表中呢,增加了一个这样的冗余字段。啊一说呢,应该明白,好接着我们再往下看啊说呢,我们现在比如有两个表啊,一个呢叫商品的一个流水表啊,就我们这个表流水表还有呢,叫商品的一个信息表啊,就是下边这样个表啊,这个信息量呢还挺大啊,流水表的话呢,这个信息量是很大的哈,400万条记录,然后商品这个信息表里边呢,就是具体一些商品的哈,只有2000条这个商品的记录,好那如果呢,你会发现咱们经常性的去访问这个流水的这个记录信息。而且在访问的过程当中啊,诶我们这两个表的话呢,它其中有一个呢叫呃是不是叫商品编号,通过这个字段呢,是不是进行了一个关联关,呃关联对吧?呃这就相当于在我们这表里边,就是外建这个呢,就是主件。
06:10
我们在进行这个商品这个流水信息的查询当中,经常性的去查看一下你这个商品的呃,名称是叫什么啊,你要光看这个商品的编号呢,很这个抽象的一串号,你也不知道这到底它这个这个这个流水涉及到的这个商品是什么,对吧?诶我们经常性的要把这个字段呢加上。啊,那你要是按照我们冗余的呃,范式的要求来讲的话呢,那这个字段肯定是独立的只在这个表中的啊,那你要是经常关联查询的性能不是变低了嘛,怎么办呢?诶,我们就考虑把这个叫goods name这个字段呢,增加到我们这个叫流水的这个表当中,诶然后呢,这时候你在经常性的做这个查询的时候呢,我们就不用再去关联的另外一张表上。啊,这个性能就要好一些。啊,这是我们说的这个例子,行,那我们光说了说有好处有好处,那么真实的能不能举个例子来体现一下,确实呢,我们就增加这个冗余的,然后呢,进行查询的时候呢,时间呢,确实有所缩短,哎,下边呢,咱们给大家举个例子啊,就是这个举例四。
07:06
这个举例四呢,我用的是这样的两个表,一个呢叫课程的评论表啊,叫class comment,一个呢叫做学生表啊,叫student啊,这两个表。然后呢,下边呢,我们去模拟这个对应的一些数据,咱们做这个操作,那这块的话呢,我就呃把这个代码呢,直接呢,先提前粘出来了啊,先提前粘出来了啊,咱们就直接呢在这去说,那现在新建一个这个是不是该零六了。啊,这个咱们叫这个,哎,反范式化的一个测试啊。哎的一个使用吧,诶这个咱们这样说吧,嗯,这个。嗯嗯,这个数据表的一个,呃,设计规范是吧,这就是咱们整个这一节的一个题目啊,然后下边呢,是咱们这个反反式化的。哎,范式化的一个举例,OK,行,那我们这块呢,把它呢,CTRLCCTRLS保存一下啊,零六已经有了,那我们这个呢,叫零七。
08:01
哎,保存一下。哎,这个我们改成叫零七好了,那这块呢,大家直接看我这个例子啊,那首先呢,我创建了一个数据库,叫艾特硅谷DB3啊艾DB3就这样一个数据库,对吧?然后呢,我们使用这样一个数据库,然后呢,首先呢创建一个表叫做学生表,有学生ID,学生姓名和他创建的一个时间。OK,然后下边呢叫课程评论表,就是学生的话呢,需要针对某个课程进行评论,就这个评论表里边呢,有这个评论的ID,然后呢,这个具体的课程的这个ID,然后呢这个评论的具体的内容,然后这个是评论的这个时间,还有这个学生的ID,就谁评的,那跟我们这个的ID呢,是不是做了一个关联,对吧,那这呢,我们也写这个外界啊,这个大家知道这个事儿就行,这个表的话呢,我都已经创建好了。好的就好了哈,那这个呢,你先别管啊,就第一个和这个第三个好,那接着往下的话呢,我们就要往这两个表里边呢去添加数据,首先的话呢,我这创建这个存储过程,这个存储过程呢,就是用于向这个学生表中呢去添加数据的啊,这个我标注一下啊说创建。
09:01
来创建啊像。啊,学生表中来添加这个数据的这个存储过程,OK,然后呢,这个存储过程呢,我们就创建好了,创建好以后的话呢,接着我们去调用一下这个存储过程,哎,调用。啊存储过程,然后呢,这个呃,学生的这个ID是吧,哎我们说呢,是从这个,诶我这是1万是吧,从这个一万零一开始的,因为你看我们这个写了一个start,这个start的话呢,我们放在这的时候呢,有个加一加I,这个I的话呢,一开始的这个值是零,然后呢,上来的时候就有个一,所以这是从这10001这块开始好。嗯,这是这个,嗯在哪呢。诶,我刚才看的是他是吧,嗯,你看这个啊,这个start同样的道理是吧,在这啊这个呢,是从一万零一开始,然后呢,这个诶添加。这个100万条数据。哎,就是我们这么做。采数据啊,看一下啊,是不是到这100万好,这呢是我们说这个学生表,然后下边的话呢,我们创建了一个存储过程,它呢是向我们这个叫评论啊,这个表里边呢,去填这个填数据的一个存储过程啊,像评论表中。
10:09
哎,课程。啊,评论表中呢,添加数据的一个存储过程,哎,那下边呢,就是我们具体添加的过程啊,添加数据的过程。哎,这个我就不写这么细致了,针对于我们这个叫课程评论表,好这呢也是100万条数据啊。啊,一共。来添加存数据的一个存储数据的这个存储,哎,过程的一个调用啊。啊,一共这个100万条记录。行,这个呢比较简单,我提现的都已经这个都运行好了啊,都运行好以后的话呢,我们看一下这个学生表中的这个数据量,诶大家看是不是这个就100万条数据是吧?然后呢,我们再去这个select count清一下,这时候呢,是不是也是这个100万条数据啊,这个没有问题,好,然后呢,再接下来的话呢,咱们就看一下这个题目的需求了,我现在需要做这样的需求,所以想查询一下呢,针对于我们这个啊class ID呢,叫10001这样的一个课,针对于这个课呢,它的呃,评论的信息是什么,什么时间评的,哪个学生评的啊,或者你叫学生昵称也行是吧,学生的名字需要列到这儿,那我们这个评论表里边儿是不包含学生名字的,所以呢,是不是就涉及到一个多表的一个查询的对吧。
11:25
多表查询关联条件呢,就是这个student ID。然后呢,我们还按照这个评论的时间呢,是不是倒叙排一般呢,咱们看评论呢,也是看先看这个最近的是吧,所以D了,诶查询呢,诶前1000条记录,针对这个课程的行,那这块呢,我们做一个执行。哎,这时候呢,是不是就查出来我们这个前1000条这个记录是多少了啊这呢是0.016秒。诶大家可能说诶这个时间上还可以啊,能接受啊,诶那数据量呢,越多的时候呢,其实就麻烦一些,另外的话呢,这个呢,时间我们自己觉得是挺快的,但是对于这个呃,整个程序的啊,在数据表中查询来讲的话呢,其实啊也算是比较慢的了啊,也算是比较慢的了啊好,那这呢就是我们目前的这样一个场景,呃,是满足我们这个范式的要求的,然后下面的话呢,我们就想把它改造成一个反范式化的一个情况,这个改造的话呢,其实正常来讲呢,是在我们这个表的基础之上呢去改就行,我这呢,为了保留一下我们整个这个过程,所以呢,我就重新的又诶造了一张表啊,就是我们下边的一个过程啊,也就我们下边呢,就是相当于进行。
12:26
哎,这个反范式化的一个设计。啊,一个设计好,呃,那我这块呢,还是那意思啊,我保留了原来这个表,我这儿呢,就新创建了一个表,新创建这个表呢,就是把原来这个class comment表中的诶字段啊,还有我们这个数据啊,就全部的拿过来,所以这呢是一个表的一个复制是吧?诶这个大家一看呢都很清楚,那复制过来以后的话呢,其实跟我们原表的区别是什么呢?就是我们新复制过来这个表里边儿的这个,呃,一些约束啊,它其实是没有的,所以这里边呢,我就诶针对我们这个class comment1这个表呢,我们加了一个这个主件。
13:04
是吧,你得保证我们那表里边呢,跟原来那表呢,尽可能得是一样的啊OK,行这呢,我们是添加了一个组件的一个需求。打添加主键。啊,然后呢,去保证一下我们这个,呃,克拉斯COMMON1这个表。啊,它呢,还与咱们原来那个class comment这个表呢,诶这个结构是相同的啊。好,那这样的话呢,我们这个表呢就有了,然后的话呢,哎,咱们现在不是想了一个反范式化的一个设计嘛,哎,我们要查询刚才提到这样的需求啊,这是一个具体的一个需求了哈。我们在查询这个需求的时候呢,咱们希望呢,就只从这个课程评论表里边去操作了,就不要再去找这个学生表了,一言之一的话呢,我们把这个学生的姓名是不是添加到我们这个课程评论表里边,所以这时候呢,我们就ADD table啊,然后ADD,诶在这呢out这个table,然后呢,我们去ADD一个student name啊把它呢添加过来,哎,相当于是呢,哎像。
14:00
这个哎课程哎评论表中。哎,增加啊这个学生姓名的字段。行,那么增加这个字段之后呢,你这个时候呢,这个字段所有的数据呢,都是空的,那我们还得需要呢,是不是去update一下我们当前这个表中的这个字段,让他这个值呢,等于诶跟你这个学生表里边这个ID呢,得是一样的啊这呢其实也是个关联的一个关系啊,从我这里边找一条数据,找到他的student ID,然后呢,从学生表里边找到ID,然后呢,找到对应的name,然后设置过来,哎,这个呢,相当于是给啊新添加这个字段呢,哎,赋值。诶赋值是吧,诶没有问题,好,那么这样的话呢,我们这个common class comment1这个表中呢,诶各个字段就都有了,然后接下来的话呢,我们查询同样的一个需求,你不是要查这个评论的内容,评论的时间和学生的名字吗?此时的话呢,就只需要呢,从我们这个新的评论表中呢去找就可以了,还是这样一个课是吧,还是前一条记录好,此时呢,我们选中呢,做一个执行,哎,周琦。
15:02
哟,发现这个时间好像没省多少是吧,哎,我们再走一遍啊,再走齐。诶,好像没没少想象那么多,咱们这块呢,比如说增加一点,咱们改成这个啊,1万条记录啊,我们再去选择执行啊0.036,那我们上边这个呢啊,1万条记录。0.036啊,这个呢,走起。啊,0.100是吧,呃,就是整体来看的话呢,这个时间呢,肯定还是上边这个多,下边这个少的,这个应该是没有问题的吧,啊OK行呃,那么具体的实际执行时间的话呢,大家呢,再去测一测啊,就可能跟我这块有些区别,但是整体来看的话呢,肯定是我们反范的话呢,要更好一些啊更好一些。行,那下边的话呢,我们再去做一个最后的这个总结。说这个反泛式化呢,诶它的这个新问题是什么?呃,我们能看到它的好处的话呢,就是诶查询呢,显著的这个性能提升了,对吧?但是呢,我们这个代价呢,就是浪费这个空间了哈,就是我们是通过空间来换的这个时间对吧?存储空间呢,肯定是要变大了啊,这是一方面啊呃,另外一方面的话呢,这个大家是要特别关注的,我们一个表中这个字段做了修改以后,另外另外一个表中这个冗余的字段呢,是不是也要做相应同步的一个修改啊。
16:16
这个是非常大家要关注的。啊,像我们刚才说的这个里边,你这个student name呢,你是从这个student这个表里边儿呢,是不是复制过来的啊,那student表里边如果学生名字改了,是不是你这个呢,也得跟着要修改。对吧,诶很很容易理解的一个道理,包括呢,我们上边提到了关于这个,呃,部门也是一样是吧?诶你这个员工就是记录员工的部门就是记录部门的,然后你现在把这个部门的名称呢,放在了我们这个学生表,放在这个员工表里边了啊那要要是你这个部门表里边儿,这个部门的名称有修改的话呢,是不是你这个里边的部门名称也得去改一下,要不就不一致了,对吧?哎,就不一致了。好,这呢就是我们需要关注的,这是二,这倒是一个这个主要的问题,好接着如果呢,你要使用这种存储过程啊,需来支持数据的更新和删除这种额外操作的话呢,要是更新比较频繁,还是挺消耗我们的系统资源的。
17:09
就是一方面呢,你这块呢在修改啊,就是你要做修改,原来的时候呢,因为满足范式,所以呢,不会有这个冗余之说,现在你有冗余之说了,你要是频繁的去修改的话呢,我们去执行这个存储过程呢,还得花时间是吧,这都是它的这个缺点啊。啊,另外的话呢,就是在这个数据量比较小的这种情况下呢,反泛式化呢,其实体现不出来太大的一个性能的优势啊,就像我们刚才举的这个例子,我们1000啊1万啊去体会的时候呢,你发现总共呢,它的这个绝对值的差别呢,没有多少时间。啊,就是在数据量比较小的时候呢,反而的话呢,这个优势呢不明显啊,倒是让我们这个数据结构呢,涉及的更复杂了,因为你要面对这样的一些问题,对吧,这是它带来的一个新问题,还是那句话啊,任何事物呢,是不是都是有利有弊的啊,那我们呢,呃,具体要做的话呢,是不是要找到它实际的这种适应的场景。对吧。哎,还是那个,你比如说大家买这个,呃,大家买这个,就是现在呢,咱们都用这个智能手机了,那相当于这个十多年前的诺基亚飞利浦,尤其是飞利浦一个普通的手机呢,待机能够一个月。
18:11
啊,你说这些手机跟我们现在这个手机呢,是不是应该也叫有利有弊吧。啊,那什么场景下,我们还用那些手机呢,你比如说你这时候呢,去这个,呃,这个叫什么爬山了是吧,或者去这个远足了啊,这个走沙漠了啊如果呢,充电不方便的情况下呢,你是不是还得有一个特别传统的一个手机。诶,我记得的话呢,以前看过一个新闻,说一个小女孩呢,她去这个野外的,就相当于自己这个远足了啊,一不小心呢,就跌到那个,呃,林子里边呢,有一个坑就跌进去了,隔了好几天,然后呢说醒过来了,醒过来以后的话呢,然后就要求救,然后他用的是那个飞利浦的手机,然后就拨电话就拨通了,最后呢,就把它给救了,那你要是拿了一个iPhone或者呃,咱们说现在这种小米啊,华为啊这样的一些智能手机,嗯,你比如说两三天了,一天就没电了,是吧,你想打电话那就。白扯了啊。
19:01
性就是任何事物的话呢,它都有利有弊,那我们就要找到呢,呃,它在哪些情况下呢,它是有利的情况,哎,我们在这个时候呢,就用它,那凡是反式化呢,也是一样的道理,我们看看什么场景呢,它适合。它适合啊呃,首先的话呢,我们先来看一看它的使用的一个建议先,啊使用那个建议它呢,能够提高我们查询效率。对吧,哎,那我们这时候呢,要注意的点是什么呢?我们增加的这个冗余字段啊,诶尽量呢,是不是你不需要呢,经常进行修改,诶那么经常不需要经常去修改的话呢,是不是我们就规避了呃这样的这个问题了,是吧?哎这样你虽然说也需要去建立一个存储过程,但是呢,你这个就。消耗的资源就少了,对吧,下个呢,说这个字段呢,一定是查询的时候呢,是不可或缺的。啊,你要不是不可或缺,那你就没有必要加这个容积钻了,那不给自己呢,找麻烦嘛,啊,必须要用。啊,而且呢,还不经常改,诶这不就是它更好的这种场景,那么基于这两个原则的话呢,我们看看在什么场景下去使用。好这块呢,我提到了两个大的这个场景啊,第一个的话呢,就是这些历史快照的这些数据。
20:04
啊,历史快照这个数据像这个呢,就属于我们讲叫冗余信息,它是有价值的。你比如说呢,咱们平时呢,这个呃,寄快递的话呢,这个订单啊里边呢,是不是通常有这个收货人的信息啊,姓名啊,电话呀,地址啊,对吧,那么在这个订单当中呢,我们就可以考虑把这个收货人的这个信息呢,就作为一个冗余字段呢,加到这样的一个表里边了。啊,加到这表里边了,这就属于这个快照信息了,那么这个有什么好处呢?你比如说呃,我们这个用户的话呢,他随时呢,可能会去修改他的信息,呃,然后呢,这个回头呢,他说诶我们那个快件怎么没收到呢?呃,然后就查看这个订单,结果你一查看订单的话呢,如果说像原来一样,呃用户呢,比如说我们这个时候这个订单里边呢,他记录的是这个呃地址一吧,然后呢,这个用户呢,他自己把这个地址一呢,它比如说呃随后这个快递还没到的时候,他可以改成二了,如果呢,你要没有用这个反反日化的话呢,你要再去重新查看,相当于呢,还是查询的二。当然一说你看我这个快递呢,就没有到物联二,但其实的话呢,在当时他下单的时候呢,那个它记录的是一是吧,当你要是用了这个冗余,用了我们这个反泛石化以后的话呢,我们这个呢,因为是一个冗余的字段了,它就属于历史快照,我也不去修改这个字段了,那这时候呢,你可以拿出证据来说看你当初呢,下单的时候呢,你记住的就是这个地址一,不是你后来呢修改的这个地址,对吧,就是这样个道理啊。
21:21
好,这是我们说的一种场景啊,就针对这种历史快照了,说白了就是历史快照的话呢,通常就不需要常去修改了,而我们又经常会去查看,所以呢,这个也满足,呃,另外一个场景的话呢,就是提到了叫数据仓库啊,提到这个数据仓库,这个数据仓库呢,跟我们那个数据库呢,在平时使用上呢,它还是有些区别的啊。这个数据库的话呢,咱们主要目的呢,是在于这个补货数据啊,数据仓库的话呢,主要是用于这个分析数据的啊,所以像大数据里边呢,我们更多呢,就是提到这个数仓的这个概念,对吧。好,那么这个数据库呢,它对这个数据呢,要求呢,是增删改是实时性要求比较强一些啊,而我们这个数据仓库的话呢,通常它存储的都是一些历史的一些数据的啊,日志的一些数据。
22:02
诶,那么数据库的设计呢,咱们尽量的要避免这个冗余,避免冗余,但是我们这个,呃,在数据仓库这块呢,通常我们是可以考虑有一定的这个冗余的。啊,主要因为呢,就是我们其实修改的话也比较少,但是我们要进行分析的时候呢,是不是就更加的方便了,对吧。OK,行啊,那就是针对我们这个数据仓库的这个设计当中,我们可以考虑呢,诶属于历史数据了嘛,我们可以考虑呢,诶一定程度的这个反范式化好,那么这样的话呢,我们就把这个反范式化这个内容啊就说清楚了,呃,如果出于这个面试的考虑的话呢,呃,这个反范式化呢,还确实呢,呃,大家可以去谈一谈,去说一说的,在开发当中的话呢,大家呢得先啊遵循先得知道啊,我们遵循三范式是什么样一个场景,在遵循三范式的情况下。你再去考虑这个反范式,注意是这样的一个逻辑,而不是说呢,有的同学呢,一上来说说老师你说这么多说还可以呢,不存心发式,那干脆我也不学了,我就直接呢,看心情吧,我想怎么设计怎么设计,一旦我设计的要不同于三范式,被别人说了,我就说我这是反泛式法的设计啊,是因为的话呢,我们要提升效率。
23:04
啊,这个就有点扯了,对吧,诶咱们讲叫否定之否定,你得先认可我们这个知识,然后在这个基础上呢,你再看我们为什么要,诶这个违反这个反射化的要求,你不能一上来的话,你就随意了,那跟最终的这个反范式化的这个境界,它绝对是不同的,OK啊那我们就说到这儿。
我来说两句