00:00
下面呢,呃,我们来进入第二个项目。我们先首先来看一下第二个项目的一个需求啊。我们把它打开,我已经把这个静态页面呢,已经已经把它弄出来了,这个静态页面呢,大家就修修改改就可以了啊,大的大的方面大家就不用再去花很多时间了,要不然这个静态页面做的话还得费力好多时间。没必要啊。首先我们从登录页面开始。好,这是我们的一个登录页面。我们有用户名和密码。然后呢,我们可以登录进去。这是一个个人的空间啊,这个页面有些有点小问题啊,这个咱们就不纠结了。这是一个个人的空间。啊,某某某,他就进入自己的空间,这边就会显示欢迎进入谁谁谁的空间,注意了,如果是自己的空间,不会出现后面一句话,我当前页面是假的,明白我意思吗?当前我的页面是假的啊,如果是自己的空间。那么这个地方就不会出现这个超链接,不会出现这句话。
01:01
如果你进入的通过左侧,这是我的好友,我可以点这边的超链接,我点一下阿朱是吧,一点击进入到阿朱的空间,这个列表还是我自己的列表。你不能说我一点击阿朱,出现阿朱的这个好友列表不行的,这样别人的隐私就被你知道了是吧,所以这好友列表是不变的,我点了一下阿朱,哎,进入到这这个右边列表,日志的列表啊,这个叫日志的列表,日志的列表会显示阿柱的日志列表。然后同时这边会显示返回自己的空间。那么我们先说,如果是我自己的空间,左侧显示好友列表,右边显示日志列表,然后这边出现一个超链接,叫发表新日志,当我一点击发表新日志,是不是这个部分,想象一下这个分会出现一个表单,写标题啊,写内容啊,一点击发布是不是就添加了日志了?哎,就这样子。再来,然后呢,这是我的日志列表,OK,我们不考虑分页啊,就不考虑分页了。
02:02
然后呢,我可以点击我的某一篇日志,我可以点进去。当我点进去之后呢,我就能看到当前,哎,这个是。当前这个日志的主人,他发了一个标题。啊,因为我当前的分辨率问题,这个日期呢,跑到下一行了,按道理来说是日期和这个标题是在同一行的行吧,同学们啊,因为当前的分辨率比较小啊,大家应该能想的想象的出来啊。行,然后呢,这边有个头像。发表这个日志的这个人的头像,他的昵称,然后呢,这是一个标题啊,下面然后呢是一个内容。好,这是一篇日志。然后呢,因为我当前是在自己的空间里面,所以呢,我把鼠标放在我标题的这个单元格上面去的时候,它会显示显示一个小的删除按钮。当我点击删除按钮的时候,可以把这篇日志把它删掉。当我鼠标离开当前这个单元格的时候,这个小图标会会消失。这是一篇日志。然后呢,这篇日志呢,下面有每一个人的回复。
03:00
哦,这是他的好友对吧,段誉,哎,给他的做的一个回复,上面这个回复冒号后面出现的这个冒号后面内容是不是就是这个标题啊。啊,回复某某某某日志,然后什么时间回复的,下面是他回复的内容。然后针对于这个回复的内容。这个乔峰是吧,主人,主人又对他的回复做了一次主人回复。就这样的。好,做了一次主人回复,那么主人回复于什么时间?哎,也把它写在这。好了,然后下面是其他的回复者对吧,其他的回复者所所所做的回复,那你看一下这一篇回复主人已做过一次回复了,一个回复主人只能针对这个回复做一次回复。那么你看一下这个回复是不是主人没有做恢复啊,所以当我把鼠标放上去的时候,它会出现一个叫主人回复。你点错链接,哎,在这边可以出现个表单。啊,一点就超链接,那么我会在这边出现一个表单。啊,主人回复一点击添加,哎,就添加一个。
04:04
行吗,同学们?那下面这个地方我可以添加回复。添加回复,你对自己的日志你可以做回复嘛,或者你进入到别人的空间也可以添加回复嘛,回复的日志标题就自动的就是当前这个日志回复的内容,你输完之后点击回复一点就回复,那就加到后面去吗?能出来不?啊,应该可以显现出来啊,行。这是我们的一篇日志详情。那么如果是在我自己的空间,我这边是一个删除按钮的。这个删除按钮和这边的删除作用是一样的。但是大家需要注意,我在删除一篇日志的时候,这一篇日志所关联的所有的回复是不是也要删除啊?那么某一个回复如果有关联的主人回复,是不是也需要删除啊?哎,就是这样的。这个功能就是这样啊,其他的这个比较比较这个呃,小的功能我就不再给大家说的,就是我刚刚所说的发表新日志啊,这个原型页面我就没有画,一点击发表日志出现一个页面,在里边出现个表单啊,你点击添加就好了。
05:11
然后呢,添加回复在这下面有。添加回复啊,添加主动回复你这边一点击这边出现一个小的表单。啊,文本框加个按钮啊,前面说请对吧,叫主动回复冒号加文本框,再加个按钮,一点击回复啊,或者叫主动回复,哎,就出来了。只要出现过主动回复的,那就不会再出现这个超链接了,就这样。那么,当我们进入到别人的空间。一点击好友列表啊,某一个人。一点击,如果当前进入的是别人的空间,这边还应该有删除吗?就不应该有了,那删除这边就是空的了,是吧,同学们就是空的,但是你可以点进去看,那请问点进去看的时候,这个小按钮还应该在吗。是不是就不应该在了,这个小按钮就就就就就就没有了啊,你只能看,然后在下面是不是可以恢复啊。没错吧?
06:01
啊,那我问一下这个主任回复这个超链接还要吗。应该也不需要你也因为你不是主楼,当年不是你的空间嘛,是吧,也没有这个。啊,然后呢,我的某一篇回复,我这个山竹还要吗。是不是也应该不能不能有啊,因为你进入的是别人的空间,你不能删除,你只能去做回复。好,这个逻辑应该也也也也也比较好理解吧,同学们应该应该也不麻烦啊,应该也不困难。这是我们一个需求,需求我们把它说完了,那下面呢,咱们需要来针对他,咱们需要来做个数据库的设计。视频我就不断了啊。现在。我来新建一个啊。这是PROJECT20,我来新建个叫二幺。
07:00
把这个勾勾上。下一步。PROJECT21。这个重1.0。好,就这样。然后点击finish。好的,那么我们把这些页面全部把它挪过来啊,咱们要不先不挪吧,咱们先做数据库分析。我们在这边新建个readb。这是第一步啊,或者叫业务了解。需求熟悉。大家以后到企业里面去也是一样的。第一步,一上来并不是让你写代码。第一步,你一定要去熟悉我们所开发的这个系统的业务需求。如果业务需求理解的不准确。或者理解的有偏差,那么你写出来的代码一定是错的。想都不用想啊,很多时候我们很多有些企业不仅仅是大家了,有些是我们企业因为这个项目进度的问题,因为要和别人竞争,成本报价已经压的很低了,如果我们的工期再延的很长,成本一上去,那我们根本就赚不到钱,甚至是亏本的。
08:13
所以呢,我们要我们要尽快的以最短的时间把这个系统把它开发出来,因此我们就会去尽量的去压缩这个这个这个开发的这个时时长。那么就很多时候就会导致什么呢?导致我们前面的业务需求的分析。不够充分。急急忙忙的开始搭建这个搭建这个项目的架子,然后就开始分工,分工之后就开始写代码。写着写着,客户说不对,你的这个需求理解不对,我的我所要求的业务不是这样的。那怎么办?程序员?好几个程序员这一周的活白干了。啊,写的代码一点用都没有。因为需需求理解有错误嘛,有偏差嘛,那那再改。是吧,那你这个反反复复,反反复复,先不要说这个这个这个这个员工士气啊,咱们开发人员的这个士气的问题啊,士气应该会很大受很大的打击。
09:06
第二个这个项目的这个风险绝对是突然一下猛增。啊,所以说第一步我们熟悉。业务需求。把这个酗酒一定要吃透。第二步。需求我们熟悉了,我们要去做数据库设计。这是我们第二步,非常非常关键的事情。数据库的设计。一般情况下。一般情况下。如果这个系统比较小,那数据库设计就交给某一个人去进行。让他吃鸡。设计个三天,设计一周,设计完之后,下周一咱们来做个头脑风暴。咱们这个开发小组总共六个人。咱们六个人今天上午半天啥事都别干啊,所有人请你把工作全部安排好,今天上午所有的人你不要安排自己的事情,我们上午半天全部开会。就只做一件事情,做数据库的定稿。数据库设计的定稿,数据库设计的这个程序员,今天上午你要准备好对吧,准备的比较充分,你要给他讲你是怎么去设计的。
10:08
啊。就是这样的,那如果说我们这个系统的规模比较大,这个项目的。量比较大。那一般情况我们会分模块,这个模块交给谁,谁设计,那个模块交给设计谁设计,好几个人同时在做这个数据库设计的事情。啊,就是这样的。我们的我们的系统的也说老师,那这个数据库设计这个能有多大呢?千万不要小看数据库设计。啊,数据库设计还是比较的一个能够考验一个人的技术功底的。并不是说你会会写代码,写价格代码是吧,If啊,付全款和设计方法并不是这些。啊,一个数据库设计还是非常能够考验一个程序员的一个一个技术功底的。啊,之前我之前我就做过某一个模块的事情,一个模块80多张表。啊,一个模块,一个模块80多张表啊,那个设计还还是我觉得在当时对于对于我而言还是还是蛮难的。
11:04
啊,数据库设计的两周。设计了两周的时间。但是大家要知道,在两周,两周之前的时间对于我而言就是噩梦,为什么两周之前我需要去去去看业务?一大堆文档,这一个一个一个系统的文档,200多页,300多页,这一看吓死了,之前都是word文档,现在还好一点,现在咱们的原型设设计已经做的非常成功了,但是在很早之前的时候,咱们原型设计很少,基本上都是文字加表格的方式,大家想象一下。很多同学都做过毕业论文。啊,当然这个大家毕业论文还感触还不深啊,咱们很多同学的毕业论文都是。都是大家都懂的是吧,就不说了啊好。这个需求文档动不动两三百页啊,现在比较好,为什么说现在比较好,现在我们很多的这个需求的去。理解啊,我们都是接助于圆形设计的,我们可以通过X或者通过磨刀我们去做,比如说像磨刀我们可以做叫高保真的系统原型。
12:05
你这个系统原型做出来,就和这个真的这个系统已经开发好了一样。然后我们就可以先拿着这个原型去和客户进行反复的交流,反复的确认。为什么呢?其实客户他有些时候他也不知道他想要啥。他只知道我得有什么功能,但具体这功能是怎么个展现方式,怎么个表达方式,他其实也没有想好。那么他在和你交流的过程当中,对吧,如果你的原型做的很好,你在和他不断的交流,不断的交流,哎,能让他得到一些灵感,他觉得应该怎么做,应该应应该怎么弄,应该怎么弄。啊,那这样的话,其实客户的满意度是比较高的。但如果说你总是和客户总是在那边空口,在那边空谈。啊,甚至于拿着一大堆文档。说实话,客户是不大感兴趣的,客户很多时候是很反感的,因为他心里想的和你心里想的不一样,你心里想的是,尼玛,我好不容易跑过来和你讨论需求,结果你还不上心是吧?
13:04
客户,客户心里想的是,我靠,我都已经把钱给你了是吧,给你付钱了,你还让我动脑筋。大家能听懂我意思吗?对吧?两个人想的是不一样的。啊,所以所以所所所以所以这个我们有了这个原型设计之后,我们一开始现在我们不太可能会拿着这个一大堆的文字去和客户,客户去去交流了。仅仅是在最后我们要签合同的时候,我们的需求文档是要是要把它归并到合同里面去的,是要有法律效应的,那这个时候才会形成一大堆的文字。但是前面我们在做这个,在做这个需这个需求的一些一些确认的时候。啊,在定需求的时候,我们全部都是拿着这种这种X的原型,或者是磨刀的原型去和客户在进行交流。啊,大家以后工作其实就知道了,但是说实话啊,这个需求的这个分析。
14:00
和甲方的这个交流的沟通的这个过程,他的技术含量远远要比你做开发要高得多。因为你在做开发的时候,你是和机器打交道。啊,但是你前面的你是在和人打交道是吧,因为人是一直在可变的,人是比较复杂的。啊,所以这个是比较考验大家这个综合能力的一个地方。可能这个你你干活,你你干着干着,甲方对你很满意。是吧,突然给你冒一句,小伙子,要不到我们这边来吧,是吧,甲方一下给你挖墙脚,就把你挖挖走了,因为你是乙方啊,然后你们老板还不还不敢吱声。是吧,为什么,因为不不不敢得罪嘛,大不了我少我损失一个程序员嘛,对吧,心里可能像割了一个肉一样,比较疼嘛,但是也不敢吱声,你一吱声,你后面单子还要不要接了,是吧,就这样。啊,所以你好好表现是吧,但是也不能表现过头啊。你好好表现,可能你干着干着你就干到甲方去了。是吧,以前你这个是对对别人你要主动点头,哈腰微笑是吧,现在你是甲方往那边一坐,嗯,请坐吧,是吧,这态度完全不一样。
15:04
好,扯远了啊,这下瞎扯的啊。包括什么呢?包括包括啊。我们。我我我就不说具体的甲方是甲方是是什么样的性质的单位了啊,以前这个我做过需求分析。啊,今天和今天和王某某是吧,和他谈,哎,需求定好了相气氛相当融洽啊,这个王某某他也显得非常的专业是吧?好,聊好了,需求确认好了,需求确认好之后,我们就回去画原画原形。啊,把我们的原型提提出了一些修改意见,把原型重新进行设计好,确认好之后,第二周我们约定好时间,第二周周一再过去确认,所以我们第二周周一又过去确认,确认的时候王某某出差了。啊,出差不在,变成了李某某在是吧,就和李某某聊的时候,他们俩是平级的,他们俩都是部门的副经理啊,或者是某一个科室的副科长是吧。这个李嬷嬷一看,这设计的什么玩意儿,太不专业了。
16:00
是吧,又对这个设计的这个这个内容需求又重新大,这个这个叫大动干戈,重新做了一次更改。啊,那不行啊,硬着头皮再改,第三周周一再去确认,然后这个时候王某又回来说,什么情况,你怎么对我们沟通的这个情况一点都不了解啊,是吧?这和我们当初聊的这个完全不一样。啊,这个这个这个这个是非常非常,这是非常郁闷的一件事情。啊,非常非常郁闷的一件事情,是非常耗精力的一件事情。他和具体的技术是没有关系的,他是和人打交道的,一个一一个哲学问题啊,这个话不能说太细是吧啊。不扯了,抓紧时间啊。好,这个是叫数据库设计,那么我们数据库设计呢,我们其实分成三步,同学们第一步咱把这个都学过的,第一步我们叫抽取试题。第二步,分析其中的属性。第三步,分析实体之间的关系。好吧,同学们,我们是要经过这三步的。哎,是不是啊,我们数数据库设计的三个步骤,那么第一步我们要抽取实体,还记得我们刚刚所说的需求吗?
17:06
好,想象一下我们刚才所说的需求,第一个我们有个登录界面。啊,用户。用户进行登录。第二个登录进去,进去之后登录成功。登录成功,显示主界面。啊。然后左侧显示好友列表。左侧显示好友列表。上端。显示幻影体。欢迎谁谁谁进入空间。如果不是自己的空间。如果不是自己的空间啊,显示超链接。返回自己的空间。是吧,同学们,返回自己的空间好。下端。显示日志列表。对吧,显示日志列表再来。
18:00
我们可以,我们可以针对一篇日志查看。日志详情。那么日志的详情里面就包含日志本身的信息。日志本身的信息啊,作者头像。立春。日志标题。日志标题日志内容。日志的日期。等等对吧。这是我们日志详情的信息。再来,我们还包含什么呢?这是日志本身的信息。我们还包含什么呢?我们还包含回复的列表。回复的列表。诶,这个字不一样大啊。就就这么地吧,啊,回复的列表。那么回复的列表包含回复者。回复者的头像。昵称。啊,回复标题其实就是日志标题吧。所以我们就写个回复内容。
19:00
回复日期等。这是我们回复,然后呢,我们还有主人回复。主人回复。信心。哎,就是这样。这是我们查看一篇日志的详情。然后呢,我们也可以去删除一篇日志。我们可以删除日志。我们可以删除特定回复。我们可以删除特定主人回复。当然,我们也可以添加日志。添加恢复。添加主人回复是吧,同学们。然后呢,我们还可以进入到别人的空间。点击。左侧好友。链接。进入好友的空间。查看日志。好,就这样吧。所以大家帮我,大家现在就放空啊,不要看上面了,抽取实体,大家想想我应该有哪些实体呢?
20:02
帮我想一想。第一个我肯定要有用户。还有吗?好友,好友不也是用户吗?用不用不知道,熟悉吗?咱们第一步出具实体。用户。日志。回复就回帖嘛。硅铁。主人回复。是吧,那么这个用户呢,用户听好了,用户同学们,我把它分成两个。第一个是用户登录实体。第二个是用户详情信息。什么意思?用户登录信息,大家现在我们进行注册的时候都是快速注册,或者叫一秒注册。你根据一个手机号就能给你注册,注册完之后那个用户名可能大家也看不懂,或者说那个什么账号大家也看不懂,随机生成的。
21:01
是吧,然后你注册完之后,你先用。然后等你有时间的时候,你是不是再可以去完善你的个人的详细资料啊。是吧,同学们,所以我们用户信息其实可以分成两个,分成两张表。啊,就是这样的。再来。好了,用户的登录信息,用户的详情。日志回复主任回复啊,我们就把它分成这五个实体。那么实体呢?实体我们使用的是呃矩形来进行表示,我们把它画出来。所以我们这边有一个用户稍等啊,把这个画的。画成这样啊好,这是用户。用户登录信息。用户登录信息。我们还有一个叫用户的详情信息,把它画在这。
22:01
用户详情信息。然后呢,再来,我们还应该有日志。这个尸体。好,我们写一下日志。我们还应该有回复这个试题。回复这个尸体,我们还应该有主人回复这个尸体。哎,就是这样是吧,应该有这么五个。一个两个,三个,四个,五个,再来我们要去分析其中的属性。啊,我们要去分析其中属性第一个。用户登录信息。用户登录信息里面,我们应该有账号。我们应该有密码。我们应该有头像。我们应该有昵称,这些都是我常用的信息,是不是应该有这么四个?再来。用户的详情信息。
23:02
详情信息。用户的详情信息里面,我们比如说有真实姓名。我们有星座,我们有血型。血型啊,我们有邮箱啊,我们有手机号等等等等,这个就不写了一大堆。因为咱们开发一会用不到啊,想起信息就把它意思一下。再来第三个,我们应该有日志,日志应该有什么?标题。内容。日期。是不是啊,日期是不是要有坐折。对的吧,你这篇日志是谁写的嘛,你得一个作者再来回复,回复应该有什么?标题就没有了,标题咱们刚才写的就是就是回复冒号加上日志的标题嘛。哎,我们应该有内容。日期。作者,回复者是谁吗?作者还有吗?哎,非常好,我们点个日志。你这个回复是针对于哪一篇日志之作的回复吗?咱们得需要一个回复。
24:00
再来主动回复内容。日期作者,你可以把它加进去。你可以加作者。啊,没有关系的,可以加速的。好,再来回复,是不是得回复主动回复,当前这个主动回复是针对于哪一个回复做的主动回复。没错吧,同学们好。这是我们这是我们这个啊,对实体,我们对它的属性所做的一个分析。所以我们把它把它再画一下我们的属性,我们使用的是不是椭圆啊。是吧,同学们,我们这个称主叫一价图嘛,我们来画一下。好,所以用户的登录信息第一个。账号。账号。嗯,就感觉太小了。扩大一点啊。
25:02
好账号。第二个密码。密码。第三个昵称。第四个头像。我们不考虑文件上传,比如说头像的自定义,这个不考虑啊。头像怎么写文件呢?真是的。头像啊。登录信息。交给他。密码交给他。昵称交给他。头像交给他,哎,就这样。好,这是我们用户的登录信息,那么用户的详情信息我就简单写一下吧。用户的详情,第一个真实名称。
26:01
第二个星座。啊,什么邮箱是吧。还有比如说手机号等等都不写了啊,就这样吧。好,第一个真实真实姓名或者叫姓名吧。第二个星座。地藏什么性别是吧,行吧。这手机号啊,不写了行吗。就这样的。这是用户的详细信息。再来。我们还有日志。还有回复和主动回复,好,我把这几个位置把它稍微调一下啊。好日志呢,我把它放到这个位置。回复呢,把它放到这。差不多啊,这样应该差不多行,把这个挪到这边。
27:02
主动回复。没问题,就这样。那么我们的日志。有哪些信息呢?我们刚才描述的第一个标题,你得有。标题是吧?第二个内容你得有。内容。第三个你这个日期你得要有。第四个作者里的要有,没错吧,我们得有这些信息。标题。内容。日期。作者。啊,这四个是必须的。把它画出来标题。内容。日期。这是日志。再往下我们应该有回复。回复呢,第一个内容得要。回复的时间得要。谁回复的,得要作者是谁是吧?然后你回复的是哪一篇日志,是不是同学们?
28:00
好,就这样。所以我们写一下第一个内容。第二个回复的日期。第三个作者是谁?第四个,你的日志是谁啊?回复的是哪篇日志?好,最后的内容。我得日期。我得坐这。我得日志。就这样的。再来,我们还有主动回复。主任回复。我们有内容。回复的时间。针对于哪一个回复做的主动回复。当然,我们也可以把作者。把它加进去。啊,一会儿我们再来讨论哪些属性,好像有有可以有,好像又可以没有。啊,没有感觉有点别扭,但你加上去就感觉有些多余,咱们一会儿再来讨论。好,就差不多就这样吧,行,我们写一下,第一个是内容。
29:00
第二个是日期。第三个是作者。下面一个是回复。那么主动回复。内容日期。作者回复。这是我们第二步。再来。下面一步,第三步,我们要去分析实体之间的关系。我们来考虑一下。比如说。用户。用户登录信息。和。我们的用户详情信息。之间,他们之间是什么关系呢?好,他们之间是一对一。一个用户登录信息对应一个用户详情吗?好,再来。第二个是我们的用户。和谁呢?和日志之间的关系?哎,我们的一个用户可以会有多个日志。
30:00
一个用户会拥有多个日志,就这样的。再来第三个日志。和回复之间。是什么关系呢?哎,他也是一对多。再来。恢复。和主人回复之间。主任回复致敬。好,他们是一对一。啊,其实我们不用分的很细啊,这个一对一其实和上面的一对一是有区别的,这个指的是主键关联主键的一对一。下面这个其实指的是foreign fk。外键叫唯一,外键叫UK吧。UK UN key唯一外键啊一堆,但是这个其实在我们my bet里面,其实分的不需要分这么细啊,咱们后面会讲MYT啊。我们就只要知道一对一就可以了啊,这个是一对多,还有谁和谁之间的关系呢?
31:02
用户和我们好友之间的关系。他们之间是什么关系呢?一对多吗?哎,多多得多。一个人可以拥有多个好友。同时,一个人也可以成为多个人的好友,是不是啊,那不就多得多吗?这是他们之间的关系。实体和实体之间的关系,我们使用菱形来进行表示。我们使用菱形来进行表示。好,把这个尽量的往这边挪一点啊,这样空间可以节约一点差不多。那么。用户的详情和用户登录信息之间,我们选用菱形。来表示。好,他们之间是一对一。
32:01
我们把它连上去。一对。就这样吧。然后呢,用户和日志之间,他们之间是什么关系啊。是不是一对多?用户。和日志之间,他们之间是一对多。那么日志和回复之间呢?一堆多一个字之后,是不是会有多个回复?把它连上。一篇日志。对应的会有多个回复。就这样的。那么用户呢,和回复之间也可以存在关系。比如说多个回复是属于同一个人。是不是一个人可以做出多个回复?
33:00
当然,具体他们之间要不要有这种关联的关系,取决于我们的业务。那么这种关系到底是单向的一对多?还是多对一,还是双向的,既有一对多,又有多对一,取决于我们的业务,看我们的业务需要。回复和主动回复之间,他们是一对一。好,我把它标在这。一对一,就这样的。好,差不多。那么这个当中有作者。这么一个作者啊,那么他和用户之间其实是存在一个关系的,我们把它标一下。好,把它标在这。这是多是吧,同学们,这是多哎。
34:00
不是吗?对的吧。一个人可以做出多个回复嘛,多个回复都可以属于同一个人嘛,这不是一对多吗?好,就这样子。当然这个主动回复,他这边也有个作者,这个作者他和用户之间也是有关系的,是不是也是多对一啊。哎,是不是一个人是不是可以做出多个主任恢复啊?哎,就这样,那么具体的,我刚刚说过啊,我刚给他说过这个作者。这个字段到底要不要?这是我们数据库设计的一个问题。所以呢,我们在数据库设计的时候,我们也是稍微知啊,稍微这个学习了一下,这个叫数据库的范式。在我们的实际的生产环境里面,不是实验室啊,是正常的生产环境里面。我们的范式数据库范式,一般我们会用了前三个范式,第一范式、第二范式和第三范式。啊,后面的什么第四范式啊什么等等等等,咱们一般不会碰到。那么第一范式它指的是什么?有印象吗?第一番是。
35:03
稍等一下啊,把它保存一下。好。数据库的范式。第一个。我们有第一范式,第一范式它要保证的是列不可再分。这是第一方式所要求的。如果你的列还可以再分,那么是达不到第一翻式的。比如。我们购物,你的收货地址,假设你的收货地址,假设你写的是。上海市。松江区对吧,什么大江商厦啊,上硅谷,什么吉林几。你这么去写这一个列的话,那这个字段可以再分吗。这个字段可以分吗?这个字段不能分吗?上海市是不是可以把它分出来?
36:01
松江区区域是不是可以分出来?具体某某某街道是不是也可以分出来,然后再加一个详细地址。所以我们地址收货地址这一列可以分成N多个列。是吧,所以说我们在设计的时候,你要把它分成多个列,当然咱们同学没还没有这个,呃,还没有太多的这种数据和设计的经验,大家可能会有疑惑,老师干嘛要分呢?我写成一列,我觉得挺好的。啊,我们主要考虑的是数据冗余的问题,大家想象一下。你是在上海市,得有多少人在上海市?那大家的这个收货地址里面都会出现上海市这三个汉字。想象一下,假设我们有个数据字典,数据字典有一列。数字假设叫001,我从啊001这个好像有点高调了是吧,002吧,北京001是吧,上海001啊,就写的叫上海市。然后或者叫二号。二号上海市,然后我在我的收货地址里面有一列专门我写的是数字二,其他人是不是也写的是数字二,那你想象一下,我数据库里面到底是我存储上海市三个汉字。
37:10
还是存储一个数字所占用的空间大,前者还是后者?肯定是前者占用的空间大嘛。那如果说有100万个人,1000万个人。都是存储的是汉字,那你的数据库里面是不是上海市就出现了1000万遍。那你想想得占用多少空间?如果我出现1000万个数字二,它的空间节约应该比上面要只有它的1/6吧。假设我们一个汉字存储两个字节,就不要说三个字节了,咱们就存储俩字节吧,你得需要六个字节,但是咱们一个数字,一般情况下我们需要一个字节就够了。是不是我们的空间就缩减为之前的1/6啊?你还没有说其他列呢,我就光这一个列我就缩小了1/6,那你可想而知,如果你的数据库设计不规范的话,将会导致你的数据库是不是很冗余啊。
38:00
我这么去讲,大家能感受到吧。对吧,所以这是第一方式叫列不可再分。好,第二范式指的是什么?第二范式指的是一张表。值。表达一层含义。或者只描述一件事情。一张表只表达一层含义,或者只描述一件事情。这是啥意思呢?比如。比如。比如我们有一个叫学员学员档案的一个基本信息表。我们在学员档案的基本信息表里面。我们描述的学员的姓名啊。出生年月哦。她所学的专业哦。他学的哪些科目啊,每个科目的得分啊,等等等等,如果全部放在里面,那这个表是不是就不再是描述他的基本信息了?还包含他所处的院系,他所学的专业,他所考的考试成绩,那这个表就变得混乱不堪。
39:07
啊,所以我们关系数据库第二方是强调的是一张表,只表达一层含义。啊,但是凡事都不能说的太绝对,在我们关系数据库里面,我们要设计的是一张表,只表达一层含义。那么在我们有些非关系数据库里面,我们恨不得所有的内容全部只在一张表里面进行标书啊,那你想这这这这这两个这两种理论是完全相悖的。啊,咱们反正就不再去扩展了啊,当前我们的关系型数据库第二方式,我们指的是一张表,只表达一层含义。你要描述学院的信息表,那就指标描述学院的信息。你要想描述学员他所所在的院系,所学的专业,那你就专门再出现另外一张表。第三个,你要想表达学员他的选修科目以及所对应的成绩,那你再写一个成绩表就可以了。
40:01
他们应该都是分开的,不能放在一张表里面。好,这是第二方式。第三番是稍微有点比前面两个不是很好理解,前面两个应该非常好理解吧。第三方是指的是什么?表中的。表中的每一列和主见都是直接依赖关系。而不是间接依赖。而不是间接依赖。这是什么意思呢?比如说。比如说。我给大家刚刚所看到这个作者,如果我把作者这一列加进去,其实他就不符合第三范式。为什么?主人,回复这张表里面是不是有个叫回复?回复是不是能找到具体的回复,回复里面是不是有个日志,日志是不是就能找到这里面的作者,所以因此我这边不出现作者,其实我也是能够找到作者的,那么我们就认为如果作者这一列加进去,它其实和我们本身这个表的主见并不是直接关联的,我们可以通过三个表,我们是不是最终也是能够查到这个作者的吧。
41:14
所以,如果我们要想让它符合第三范式,我们这个作者这一列不应该出现。能听懂吗?他其实是不应该出现的。那为什么我现在还坚持把它写上去呢?想象一下,我们不写上去,数据库设计应该是更规范了,它符合第三范式。如果我写上去,它只能符合到第二范式是吧?它的规范度没有那么高。但是为什么还要坚持写上去?因为我会发现,如果不写,我得需要经过三表连表连接查询,三张表进行表连接查询,我才能知道主人回复这个主人到底是谁。是吧,同学们。那三个表进行表连接查询和单表查询,你觉得哪个更容易一些?
42:00
想都不用想,一般情况下都是单表查询更容易一些。是吧,所以我此处我要做的事情是什么?也就是数据库的性能。和数据库的规范度,我在这两者之间做一个抉择。啊,这个邻家女孩有两个,到底选哪个邻家女孩呢?是吧,这比较纠结。啊,这个现在年轻人都这么豪横吗?对吧,小孩子才做选择是吧,成年人这个都要是吧。所以呢,我们要在数据库的性能和数据库的规范度之间,我们要去做个选择。某些情况下,我们就需要去牺牲数据库的规范度,降低数据库设计的这个范式,从而能够提高我们的查询性能。而某些情况情况下,我们宁可牺牲一些查询性能,我们要去提高数据库设计的方式,因为因为我们数据库设计的方式越高,它出现数据冗余的风险就会越低。
43:00
一个是空间嘛。一个是时间嘛。是吧,到底你选时间还是选空间,我们要根据我们的业务来。假设我们这个功能。假设我们这个查询功能偶尔的采用,查询的频次非常非常的低。那我认为我们要优先倾向于空间。是不是,嗯。你查询性能再差,多个表进行查询,你反正查询的不多。你反正查询的不多是吧?我们要更倾向于空间,所以我们要去提高我们数据库设计的方式。那么某些情况下,如果这个会经常被查询,经常被被展示。啊,经常要知道他展示显示他的信息反复的被查询。那你想都不用想,我们要要去降低他的范式。要要适当的多一些冗余,从而能够从而能够提高它查询的性能。好吧,同学们,OK。所以。我们在这边写一下啊数据库。
44:01
啊,数据库设计的范式和数据库的查询性能。性能。很多时候。是相悖的。很多时候是相悖的。我们需要。根据实际的啊,实际的业务情况做一个选择。需要去做一个选择。第一种查询频次不高。不高的情况下,我们更倾向于。更倾向于。啊,提高数据库的设计方式。从而。啊,从而这个叫提高啊存储。存储效率。是吧,从而提高存储的效率。啊,反之如果查询频次非常高的情况下啊,频繁查询,或者讲查询频次比较高的情况较高。较高。
45:03
较高的情形。情形。我们更倾向于。更倾向于牺牲。数据库的规范度。啊,或者叫降低数据库设计的范式。允许,允许。允许特定的冗余。特定的冗余。冗余,从而提高查询的性能。行吧,同学们,从而提高查询的性能好。后面大家反倒是要进入到实际的工作场景,再去慢慢的去体会。很多时候我们并不是理论,并不是按照理论一套一套的,而是一定要根据我们的业务需求来定。好,这是我们数据库设计相关的。
我来说两句