00:00
好,同学们,咱们接着来讲这个第11章叫做数据库的一个设计规范啊,那这一章的话呢,主要呢,我们针对的就是数据库当中的一个表啊,表呢,我们在设计的时候呢,需要遵循哪些要求啊,我们就提到了这个范式,以及的话呢,我们在这个计当中啊,会涉及到了关于这个实体属性,还有他们相互之间的关系,那就对应的我们叫ER模型,那再者呢,就包括我们一个工具啊,叫power designer的一个使用。OK,整个来讲的话呢,咱们这一章的难度话呢,其实不算特别高啊,难度呢不大,来我们这块呢,就一个一个来进行这个讲解,首先的话呢,是一个概述,说我们为什么需要数据库的一个设计啊,这个问题问的呢,其实是比较幼稚的哈,那我们说呢,进行数据库设计的话呢,主要我们关注就是表的设计了,毫无疑问对吧,那我们呢,可能要面对很多的问题,比如说呢,呃,用户呢,到底是需要存储哪些数据呢?我们要把哪些数据呢,给它持久化保存到我们的表当中呢?诶这呢,其实是我们要考虑的第一个问题了。那以及的话呢,我们把这个数据呢,已经存储到表里边了,我们这个如何保证这个数据的一个正确性呢?啊,那这时候呢,我们就提到相应的一些约束的检查,有些约束呢,我们需要在这个业务逻辑层面呢去做,那有一些的话呢,我们需要呢,在这个表层面上去做啊约束呢,咱们以前都讲过了,对吧,那么再接下来的话呢,我们如何呢,去降低这个数据表的一个叫数据的冗余度。
01:17
啊,冗誉度这呢是我们在设计表的时候呢,非常啊敏感和在乎的一个点啊,你想想,如果我们这个表数据量不大的时候呢,你冗誉度高一点也无所谓啊,因为你浪费的空间呢,呃,也是有限的,但是一旦呢,我们这个用户量的这个增长啊,我们这个表数据的量呢,呃,迅速呢扩张的时候,那你这个勇于的这个数据呢,也可能成几何级数的增长,这个呢,我们就可能接受不了了,对吧?诶我们尽量的要降低这个荣誉度,接着的话呢,如何让负责数据库维护的人员呢,更方便的去使用数据库。啊,说白了就是你这个表设计成什么样,我们得基于你这个表结构呢,去写我们相关的一个SQL语句了,表设计到不好,那我们这个SQ语句的话呢,是不是也会存在相关的一些低效的问题,对吧。OK啊,整体上来说的话呢,就是数据库的应用场景呢,各不相同,针对于不同的情况呢,我们设计出来的数据表啊,它是千差万别的。
02:07
啊,很难说呢,我们有一个呃,黄金准则是吧,大家呢,只要你看到这个准则以后呢,醍醐灌顶,然后呢,呃,放置四海皆准啊,一下子就成为数据库表设计的一个大牛了啊这个不太现实。啊,你包括呢,说学习也是一样啊,啊,你说有没有什么这个呃秘诀的这种学习方法,一旦看到之后呢,这个恍然大悟啊,然后呢,学习的突飞猛进,直接考上清华北大不太可能是吧,不会有这样的这个投机取巧的这种捷径的。啊,也正因为这样的情况存在呢,具体问题需要具体分析,所以呢,随着你时间的积累,经验的积累,你的价值呢,是不是才可能会更大,对吧?那如果说简单的东西的话,所有人都能拿过来去学,那一开始的时候是个蓝海,可能价值很大,那随后的话呢,随着进来的人越来越多,是不是它这个价值也很快会降下来,对吧?呃,就像呢,一三年,呃,应该说是准确的讲是一一年,一二年,一三年啊一直到一五年的时候呢,移动互联网想做安卓开发,IOS开发啊这样的情况是吧,但确实呢,不太难啊,很多人都去学,而且薪资待遇很高,那很快的这个市场呢就饱和了,哎,就出现这样的场景。
03:09
好,那么在这个诶,像这个的话呢,大家应该也有一些共鸣哈,就是你在公司当中,不管你是写这个具体的功能模块啊,业务逻辑的,还是经行我们这个数据库的这个设计啊开发的啊,你会发现呢,不同的人呢,写的写出来的诶功能可能都能实现,但是代码呢,写的真的是千差万别,呃,多数情况的情况下的话呢,我们要是拿到别人的代码,通常都会觉得说啊,其实写的是少啊,真烂是吧?啊很少的话呢,我们拿到一些大牛写的,哎呀,会感叹啊拍拍案教局啊,说人家写的真是太漂亮了哈,这种情况有吗?有啊,但是多数情况呢,大家可能都觉得对方写的不满意啊,因为每个人的这个思考的角度啊,他可能都是不一样的。啊,当然这个代码质量呢,也是千差万别的,OK啊呃,这是我们想给大家分享的一个实际情况啊呃,现实当中的话呢,我们可能会针对于数据表这块呢,是一个什么场景呢?呃,就是我们表设计完以后呢,也把这个程序呢跑起来了啊也上线了,运营一段时间之后呢,发现我们这个表的设计啊会存在一些问题。
04:05
那那存在问题怎么办呢?呃,此时呢,如果你要是在调整这个表结构,那就必须呢,把我们这个数据呢要迁移出来,那甚至呢,这个迁移的过程呢,会影响到我们整个程序的一个业务逻辑,以及网站的一个正常访问,对吧?呃,尤其的话呢,你想我们要是只是更新一个呃项目的话呢,代码层面呢,那你就是。再重新开发一套,然后再上线就可以了,对吧,那对于我们数据的一个调整迁移备份啊,这个是非常关键的啊,因为一个公司当中最重要的呢,其实就是数据。啊,你比如说现在呃海航啊,中国人这个比如中国人民中国银行吧,是吧,要进行整个这个数据库的一个迁移了,你想想他会找一个刚毕业的小孩去做吗。啊,那他是疯了是吧,哎,那这就是这样一个情况啊好,那正因为呢,会出现这样的情况呢,所以呢,我们在一开始设计的时候呢,诶尽量呢,就要问清楚用户的需求啊,你看他后期的一个发展是什么样子的,不同的阶段呢,有时候我们一个表结构呢,也会有所不同,OK。
05:00
行,然后下边呢,会提到说糟糕的这个数据库设计呢,可能会造成如下的一些问题啊,这个呢,我就不在这儿多啰嗦了啊,大家一看呢,应该都比较清楚啊,那么良好的数据库设计呢,应该具备哪些优点呢?呃,首先第一个呢,提到就是关关于这个存储空间上呢,尽量的我们要节省存储空间啊,还是对应的我们上面提到一个冗余度的一个问题。嗯,然后呢,能够保证数据的一个完整性,就我们要的数据呢,你都能够给我们存储起来啊,你不能说因为我们删除了其中的一条记录啊,这条记录呢,不用了,确实要删,但是相关联呢,把其他一些有用的数据也删掉了,而其他这个有用的数据呢,在其他表中还没有体现啊,这就恶心了是吧?诶,这不行。然后方便呢,能够进行数据库应用系统的开发啊OK,呃,整体上来讲的话呢,我们进行数据表设计的时候呢,呃,遵循那个大方向的话呢,就是这个冗余度呢要小一点,结构呢,诶要尽可能合理一些,方便呢,我们后续呢去写这个circle啊,这就是一个大的方向,就好比是呢,咱们在上一章呢,讲这个circleq优化的时候呢,咱们这个大方向是什么呀?
06:02
哎,色后优化,哎是不是我们要达到这个响应度呢,尽可能是不是要高一些,或者你叫这个低延迟是吧?诶另外一个的话呢,就是这个吞吐量呢,是不是要尽量的大一些,诶这呢就是我们对应的这个大方向啊OK。好,那么这块呢,这个也清楚了之后,大方向有了,那下边的话呢,我们就要制定具体的一些规则细节了啊,那这呢,我们就引入这个范式说呢,在关系型数据库当中,关于数据表设计的一个基本原则或者规则呀,咱们就称为呢叫范式。那这个英文名呢,叫做normal form啊,就是范式啊,这个简称的话呢,就是这个NF了,因为是两个单词的这个缩写,他呢是在一个英国人是吧,他在上世纪70年代,诶,在关系数据库模型啊这个基础之上呢,提出来的这样的一个诶反式这样的概念。然后这个范式的话呢,呃,因为呢,我们说这个关于这个表的设计啊,我们可以设置不同的这个层级,那根据这个层级的话呢,我们就可以定义为呢,叫第一范式,第二范式,第三范式等等等这样的一些规则。
07:02
啊,这样一些规则。其实这里边儿的话呢,也不知道大家呢,有没有关注过啊,就是咱们现在呢,学习的这些,比如说计算机的知识也好,包括呢,像咱们学的数学啊,物理啊等等这样的一些自然科学,呃,基本上的话呢,咱们其实都是学的西方的这样一套,对吧?诶西方的这样一套这个自然科学,包括呢,现在的公司的管理。啊,你会发现呢,呃,管理学看似呢好像很玄妙的对吧,但是西方人来讲呢,他们还是也会定义成一条一条这种规则,呃,然后呢,这个还有相应的一些考证认证,然后呢,一点点往上去提升啊,你就比如说大家提到这个麦当劳。啊,一说到麦当劳不就是做汉堡的嘛,那你像咱们这个中餐馆的话呢,那比这个西方的这个汉堡这个复杂的多了,才是样式也很多,但是呢,他在管理麦当劳的时候呢,你发现它有非常细节的一套规则标准啊,西方人其实做事呢,就是这样子的一个特征啊,整体来讲就是从这个点上来讲啊,咱得认可,确实要好一点,你比如说咱们这个说的这个老祖宗孔子是吧,孔子呢,厉害不厉害,确实厉害啊,咱们学的那个相应的这个这个一些孔子的一些话啊,发现说的都是很经典的,但是的话呢,呃,这个从来没有告诉我们孔司告诉我们说应该怎么能够达到他这样的一个境界啊,一步一步一步步达到他这个境界,我们不知道,也没有给过我们这样的一个路径,那只是说呢,嗯,我们都是凡人,然后呢,要么呢,就是特别牛的,呃,像孔子一样的这个境界,中间呢,怎么走不知道啊,哎,这个呢,是我们稍微的欠缺的一些点啊。
08:27
OK,就是这个孔子呢,是用来让我们崇拜的,我们呢,可能很难去达到他这样的一步一步步啊培养过程啊,那么这个西方的话呢,他们,呃,基本上做任何的这个学科东西的时候,他都想着是做一个规范化的一个标准。啊,就国外化一个标准啊,像日本呢,在这方面学西方呢,学的就比较多一些啊OK,呃,当然呢,如果你学相关的一些这个呃专业的话呢,呃,只要是需要涉及到这个西方的啊,包括呢,像有些日本的这种管理是吧,它都是也是学西方的哈,你会发现了他这样的这个特征。OK,那么拉回来的话呢,关于我们这个表设计方面的话呢,也不能说啊,你就看着整吧,这不行,我们一定要定义相关的这个标准啊,那这个标准都有什么呢?来说呢,一共有常见的六种范式啊。
09:09
按照这个级别从低到高呢划分啊,分别的对应的叫做第一范式,第二范式啊,第三范式,巴斯科德范式,简称的叫巴斯范式,第四范式和第五范式啊第五范式呢,又称为呢叫完美范式,OK,那么我看到了这样几个范式之后,呃,那首先的话呢,先要明确它的级别呢,是依次递增的。啊,那么这个接数越高啊,就是越往我们这个后边这块去弹的话呢,它的整个在表的设计当中啊,这个冗余度呢就越低啊,越往后冗余度越低,那正常来讲呢,我们是不是希望追求的荣誉度越低越好,那相当于在第五范式的时候呢,我们就称为它叫完美范式啊你看这名字呢,就感觉很不错是吧?哎,这是一个另外一个的话呢,我们说呃,如果呢,你满足那种高阶范式,它一定呢就会满足相应的低阶范式。那你比如说呢,我们说这个二范式是吧,诶只要呢,你说我们这个表呢,设计的是满足第二范式的,那么它一定也满足了第一范式。
10:03
啊,就跟你说呢,呃,说呢,你是一个本科学历,那面试官的话呢,是不是就不会问你说说你有高中毕业证吗?你有初中毕业证,你有小学毕业证吗?是不是就不会问了,对吧?因为呢,你已经是本科生了,你前提的话呢,是不是一定是读过高中了,诶前提呢,一定是读过初中了,诶就是相当于我们满足这个第三范式啊前提呢,就已经默认了第一范式和第二范式也满足了,OK。像这是我们说的这个点,呃,然后的话呢,诶,这是我们说的这六种这个设计的这个规范哈,大家呢,会发现呢,其中有一个比较特别的呢,就是这哥们儿呢,他没有按照这个12345走啊,这是为什么呢?呃,因为呢,这个第三范式啊,在他后边呢,这个巴斯科德范式,他呢只是相当于在这个三范式的基础上呢,做了一个微调,所以呢,就没有把它再称为呢称为呢叫第四范式啊,你可以把它看作呢叫做改进的啊,或者叫优化以后的这个第三范式啊,就是这样个概念啊。嗯,这是一点。然后的话呢,我们再说一下在实际开发当中,实际开发当中的话呢,嗯,多的话呢,咱们关于一个表的设计啊,也就遵循这个叫呃叫科斯这个巴达科斯,这个巴斯科达科德范式了,这个见的念的很绕啊,我就念巴斯范式了哈,这个一般呢,有时候我们就不念这个科德了,巴斯范式顶多呢,也就到这个巴斯范式了,大部分啊,或者绝大部分的情况下呢,我们就到这个三范式就可以了。
11:23
啊就可以了啊呃,四五范式的话呢,基本上呢,很多人啊在甚至说呢,就做熟,有开发的人可能他都整不太清楚,呃我们这里边的话呢,到时还会给大家呢去做个介绍,但是呢,大家也主要就停留在介绍这个层面就可以了,诶我们实际在设计表的时候,一般都不会去遵循质量,那当家呢可想一个问题说诶老师不是越往下这个冗誉度越低,那为什么越往下都完美了,那为什么不去追求呢?那可见的话呢,我们这个范式啊,咱们说呢,任何事物都是有利有弊的,你越往下的话呢,冗誉度越低,但是它相对应的也会带来一些弊端,那所以说呢,我们在设计的时候呢,是不是要达到一个平衡,对吧,适可而止啊就可以啊,中庸啊,还这样的一个思想,所以呢,大部分呢,咱们就遵循三范式就行,甚至说呢,我们在有些场景下,还刻意的要破坏这个范式的规则,哎,我们叫反范式。
12:13
啊,反范式啊,反范式化是吧,这样的一个概念,诶到时候我们都会去讲这个内容是吧?OK,行,先明确我们这样的几个标准,然后的话呢,我们再来看一下,要想讲清楚这里边的几个范式,咱们需要呢,给大家呢,诶这个讲清楚两个概念,一个呢叫做这个键啊,一个呢叫相关这个属性啊,有这么几个词儿,咱们得能看得懂,因为我们讲这几个范式的时候呢,要用到这几个词,OK。呃,那首先的话呢,我们来讲一下,这个叫做超建。嗯,这个咱们还是结合着这个例子呢,去给大家去说啊。嗯,这个例子的话呢,咱们就拿这个呢去说就行啊,拿这个去给大家去讲解,好,那什么是超件呢?就是能唯一标识元组的属性集,就叫做这个超件啊,这呢叫元组,其实你可以列成就是标识这个一行数据的啊,这样属性集叫做超件,好那对应我们这里边呢,比如说咱们就看这叫求员表。
13:03
球员表的话呢,里边有球员的编号,姓名,身份证号,年龄和这个球队的编号,对吧?那么这里边这个抄件是谁呢?诶咱们先明确一下这个主见吧,主见呢,咱们大家都比较熟悉了,对吧?那我们这个表中的字段能够做主键呢?大家觉得是谁呢?是不是这个球员编号呢,能够唯一定位,那同时呢,你会发现这个身份证号呢,是不是也可以啊。啊也可以,好,那这个呢,其实这俩呢都可以考虑作为我们这个表的主见的是吧,那什么叫这个超建呢,超限呢,就是我们呃这个字段呢,呃他们本身呢是可以啊这个理解成是超建的,以及的话呢,就是只要能够为标识的这个属性集就可以言为这呢,你比如说我有一个球员编号,还有这个姓名,他俩合在一起,诶你说我们是不是能构成一个叫超检,哎,你就看能不能唯一标识我们这个呃表中的一条条数据可以吧,诶是可以的,那我们这身份证号和我们这个年龄可不可以啊,哎,也可以,那这个身份证号和这个球队编号可不可以可以。
14:02
呃,球员编号跟我们这些球队编号可不可以也可以啊,说白了就是你包含我们这个主件的啊,然后再加上其他的一些字段呢,都可以构成了,叫做超件。好就说清楚了,然后在这个基础上呢,我们谈一下什么叫做候选剑,说如果超剑呢,不包括多余的这个属性,那这个超件呢,就称为呢叫候选键。啊,大家你看刚才呢,我说这个球员编号的时候呢,我是不是就包了一个这个姓名是吧,或者说你球员编号姓名再加上个年龄,这仨合一起是不是叫超建,那其实这三个里边呢,对于我们唯一的识别一条识别表中一条记录的话呢,这个年龄根据姓名其实用不着的。对吧,用不着,那你把这俩砍掉之后呢,我们光看这个球队球员编号是不是它就能够唯一识别这一条记录了,所以说呢,这个球员编号的话呢,就是一个候选键,那另外的话呢,我们这个身份证号呢,是不是也同样的道理,它呢也是候选键,所以在咱们这个表当中啊,有两个候选键啊,就是一个是他,一个是他。咱们也可以把这个候选键呢,你可以理解成是不是叫就是最小的这个超件了。
15:02
啊,你像刚才那个超件的话呢,我们这个就是个数最少了啊,学员编号加一个姓名加个年龄,这仨字段合一起呢,是一个超件,但是他们不是一个候选键,因为这里边这俩没有用啊,砍掉。最小的就是呃,球员编号或身份证编号啊,身份证号,那么主键的话呢,就是从我们这个候选键当中啊,诶你随便选一个啊都可以作为我们的主键的,那就是我们选球员编,呃球员编号作为主键可以,选身份证号作为主键也可以啊,但是主键的话呢,对一个表当中是不是只能有一个了,但是候选键呢,可以有多个,OK,然后下下一个概念呢,叫做外键,这个外键呢,跟咱们前面讲过的外径约束呢,是一样的道理,针对于求员表和这个求对表来讲,那我们这个球员表里边有个叫球队编号,在我们这个球队表里边呢,这个球队编号呢,它呢,其实诶可以作为一个主线出现了,然后我们拿这个字段呢,是不是跟它做个关联,在我们全表里边呢,这是不是就是外键啊,啊,这个大家很清楚啊。好,下边叫做主属性,说包含在任意候选键中的属性呢就称为呢叫主属性。
16:06
诶,就是咱们实际上这个候选键也好,主键也好啊,就是它有可能呢,不是一个字段了,咱们这里边恰好一个字段,大家也见过,是不是联合主键对吧?那就这意思啊,诶就是你主键里边呢,包含的这个属性呢,那就是叫主属性啊,说白就这意思,那这个是针对我们候选键来讲的啊呃,那也就是说呢,像咱们这个这是候选键,这个呢也叫候选键,那候选键里边涉及到这个属性就叫做主属性,那就是他俩呢都是主属性,抛开这个主属性,剩下的呢,都是非主属性。那就叫非主数型,好,那这呢,咱们就通过这个例子呢,给大家把这个概念呢就说清楚了,这个大家要熟悉啊,因为咱们下边要讲这个范式的话呢,需要用到这样几个词,OK,另外的话呢,我们也可以把这个候选键呢称为叫麻把主键呢称为呢叫主码啊,这个大家了解了就行。哎,剑呢,可能是由多个属性组成的,针对单个属性呢,我们还可以分成叫主属性和非主属性是吧,这样的行,那这儿呢,我们就把这个剑和这个属性的这个概念呢说清楚了,然后下面的话呢,我们来看一看什么叫做这个具体的第一第二第三啊范式。
17:07
好,那么下面的话呢,咱们就分别呢,来介绍一下这里边儿的这些范式,那么首当其冲的话呢,是不是就第一范式啊,我们叫第一范式也行,或者有的时候呢,也称为它叫一范式啊,说的呢都是它,那么第一范式它的主要规则是什么呢?它是需要确保数据表中每一个字段的这个值啊,都必须具有原子性。啊,原子性这个咱们后边呢,讲事物的时候呢,也会提到叫acid里边这A呢,Atom是吧,就是原子性的意思,原子性呢,就是意思着我们就不能再拆分了啊,因为我们说,呃,物理世界当中呢,这个原子呢,是不是咱们裂解成就是构成一个事物的最小单位了,你别再给它拆了,那原远之呢,就我们的资料不能再拆分了,哎,就这样一个意思。好,那我们在设计某个字段的时候呢,对于字段X来讲,不能把这个X字段呢,再拆成X杠一和X杠二了,看这要是能拆的话,那就相当于你不满足第一范式是吧?诶那要是不能拆了,那就是他满足第一范式了,那像这个呢,属于我们在设计表的时候呢,是最最基本的一个要求,所以说呢,实际情况上,我们在呃这个表的设计当中啊,这个字段呢,这这这个范式呢,是一定都会遵守的啊,是一定都会遵守的。
18:16
好,那举例一下一啊,比如说大家你看我们这里边的例子,有员工ID,员工的姓名,员工的address地址和员工的mobile啊,有的员工呢,他就是有俩手机号,那有俩手机号的话呢,你看我们要是把他呢都写在一起了,像这个李四呢,有俩手机号,这个赵六的话呢,也有俩手机号,那么显然呢,我们这个呢,就不满足第一范式。因为我们这个email这个,呃,这个mobile这里边呢,它就相当于是可以再拆分,那如果呢,要让他满足的话呢,我们就得这样来处理了,这个李四的话呢,这不102嘛,那102呢,就得拆成两条记录,其中一个呢是他的第一个手机号,这呢是他的第二个手机号。哎,然后呢,这个呢,照六啊也同样的道理啊,这样的去拆分。啊,这呢就满足,那就不能再就是拆完以后的话呢,你再去拆,拆不了了,那这就满足这个原子性了,OK,好接着再看说我们这儿呢,就设计这个表呢,叫做user啊,叫做这个用户表里边呢,有ID啊,有这个username,有这个password,有这个叫user INF啊有用户信息对吧?那么这个用户信息的话呢,它这个信息啊还挺丰富的,有这个真实的姓名,有这个电话,有这个住址,我们都合在一起呢,放在这个用户信息里了,那其实呢,这种设计方式呢,就不太好。
19:25
啊,我们在实际写SQ的时候呢,可能会要调用用户的真实姓名,还可能要调用他的电话,还可能要调用他的地址,是分开的,那你都合在一起呢,不合适,所以呢,我们要把它拆分,拆分出来呢叫real name,这是一个字段,Phone是一个字段,然后address是一个字段,那就把我们这个字段呢给它拆分了。啊,这就是这样个情况,好,这两个例子的话呢,应该很清楚的表达了我们第一范式的要求了,那接着的话呢,我们再说一下,就是这个所谓的能拆分还是不能拆分,我们实际上是有主观性的。啊是有主观性的,你比如说呢,有这个这个用户名,比如用户名了,这个家庭住址吧,那家庭住址这块的话呢,有的时候呢,我们说你这个家庭住址是不是还可以再拆分呢?呃,大家你比如说我们看这个例子,那在住址方面呢,呃,一个表呢,是这样设计的。
20:13
对吧,诶那你说这样设计的话呢,我们这个地址这块呢,是不是还能再拆呢,比如拆成省,拆成拆出市,再拆除具体的这个街道这个地址,那到底拆还是不拆呢。啊,这个时候的话呢,其实就有这个主观性了,你得根据你实际这个项目的需求,你看你是不是需要呢,细分到这样的级别上,需要呢,查这个员工具体所在的市是吧?诶如果你要有这样的需求的话呢,我们呢,就可以呢,把这个做一个拆分,如果没有这样的需求,那你就把它合在一起啊就可以了,你就认为呢,这不可再拆分了,对吧?诶就这个道理,乃至一说的话呢,比如我们在存储姓名的时候,咱们这个中国人的话呢,是有姓有名,那你说我们这个姓名有必要把这个姓拆出来,名再拆出来嘛,或者像这个老外的话呢,他这个更麻烦,老外呢,有这个叫firstna last name,还有呢叫middlename。啊,比如说这个George w布什啊,乔治W布什啊,就是美国之前那个小布什那个总统啊,这个它里边呢有first name,你说我们是把他俩都把这仨呢,都拆开作为单独的三个字段出现呢,还是说就是两个呢,还是说我们就都放在一起呢?
21:15
这个主要取决于就是我们这个实际的项目需求呢,是不是要用到啊,我们查询的具体这么细力度的这个程度上。那那如果说有这样的需求,那你就把它拆开,如果没有这个需求就不要拆了,所以呢,我们相对来讲啊,是有一定的主观性,但是的话呢,呃,我们上面举的这个例子一和例子二呢,呃,基本上我们看到之后呢,还是肯定要拆的。那肯定是要拆的行,这呢,就咱们说的这叫一范式啊,应该说呢是比较简单的。
我来说两句