00:00
好,那假如现在我们已经根据我们这个呃文档或者是这个主外键关系呢,已经把这个图,呃这个捋出来了啊,然后呢,就得到一个这样的图。啊来,我们把它全放开啊。哎,就是这样,这个箭头大家应该能理解是什么意思吧,这个箭头呢,指的就是哎,这张表和这张表我们之间有什么关系啊,是不是有关联关系啊,对不对,也就是说这两张表是可以照到一起的,那这两张表是可以照到一起的,这张表也是可以照到一起的啊好,那接下来咱们接着走啊。全画出来啊。怎么样,感觉有点懵是吧?哎,好,那这个表呢,咱们就全部都给大家展示出来了啊,当然这确实很乱啊,确实很乱啊,呃,然后大家呢,怎么去看这些表,把这个关系呃放在这之后,我们最好按照什么去捋呢?最好按照咱们的业务去捋。啊,按照业务啊,那我们电视当中,咱们涉及到的业务应该有啥呀,在这儿比如说有加购物车啊,有收藏,有下单啊,有支付,还有什么东西啊,还有这个退款对不对,还有什么呀,还有领取优惠券对不对,这些是不是都是咱们典型的业务啊,啊,那咱们就按照这个业务咱们去做一下啊,那咱们现在先说最核心的业务,什么业务呢?就是诶下单啊,这要下单,那对于下单来说呀,大家看一看我们跟下单相关的,光看名字咱们就能猜出来订单表肯定跟下单有关。
01:26
对不对,订单详情有没有关系,那肯定有关系,那对不对,那还有谁跟他们有关系呢?比如说用户表,用户表跟他有没有关系啊,有啊,咱们得知道是谁下的单,对吧?那商品表跟他有没有关系呢?有,咱们得知道你下单买的是什么商品,对吧?那所以说咱们最基本上核心的几张表咱们就找到了啊,就这几张,那接下来咱们就把这几张表之间的关系咱们捋一捋啊呃,咱们在这捋捋什么关系呢?这是一个业务系统的这个数据库结构,对吧?那么这个所谓的表与表之间的关系啊,我们说的应该是什么关系啊,啊,就是这个,比如说一对一的关系啊,一对多的关系,或者是什么多对多的关系,对不对啊啊这些东西咱们也都是一些常识,我们也得知道啊好,那接下来给大家看一下,咱们就来分析分析,那咱们先来分析这两张表吧,用户表跟订单表,那他俩的关系应该是啥?
02:17
应该是什么样?显然是一对多的关系吧,对不对,哎,谁是一,谁是左,用户是一对吧,为什么?因为一个用户我是不是可能下多个订单啊,对不对,那所以说肯定是一对多的关系啊,这个很好理解啊,那接下来咱们继续啊,那接下接下来咱们说什么呢?咱们说一下这个。订单跟订单详情,他两个是什么关系。也是一对多对吧,因为一个订单里边是不是可以包含多个那个商品项啊,对吧,然后订单详情表里边的一行数据是不是就是一个商品项,就所所显然也是他跟他也是一对多啊是这样,那接下来咱们再来看啊,再来看什么看一下哎,咱们这张表跟这张表应该是什么关系。
03:06
啊,订单详情跟这个商品表,那这个可能就没有那么好想了啊,他两个什么关系啊。大模型。好像也是。一对多的关系吧。嗯,也也有可能是一对多,那谁是一谁是多呢。下边这个是一,上面那个是多吧。啊,为什么,你想一想啊,是不是我这个可能不同的订单对不对,我里边都包含了某一件商品,也是张三我买了这个这个这个这个呃,某一件商品啊,那李四呢,我可能也买过这这种商品,那王五我可能也买过这种商品,对不对,那既然在多个订单当中出现了同一个商品,那是不是相当于这一个商品对应的详情表里可能有多行数据啊,对不对,但是他在,诶商品表里只有一行,但是它是不是也是一堆多的外型,大致是这样的一个逻辑啊,这样一个逻辑。
04:03
行,那这个完成之后,咱们再来问一个问题啊,大家再再再思考一下,你说订单表啊,认真听,订单表和商品表它俩之间应该是什么关系。这个表和这个表。订单和商品表他俩个什么关系?哎,对没错,是多对多啊就这个怎么理解,你想一想啊,就是一个商,就是一个订单,订单边的一行数据对吧,是不是里边可能包含多件商品对不对,是不是,诶在这相对是多对多,呃一相当于这这边是一对多呗,对吧,那咱再反过来看呢。反过来看呢,我一件商品,一种商品啊,就是一种SKU,是不是有可能出现在多个订单里边,那他俩这个订单和SKU,那肯定是多对多的关系。啊,很多多对多啊,也是咱们现在大致分析出来的,这整套流程里边有什么一对多,有对对多啊,那问大家一下啊,在我们关型数据库当中啊,两张表如果是一对多的关系,这个关系咱们怎么实现呀?啊,怎么去实现它这个一对多的关系啊。
05:09
啊,就是怎么去保存这个关系。那其实通过咱们这个是不是外线就可以实现呀,对不对?呃,你比如说现在用户跟订单是一对多的关系,对不对,那我可以怎么办,我是不是可以在订单表当中啊,然后呢,加上一个字段,加什么字段呀,UIDUID或者叫做用户ID对不对?那这样一来是不是就能够知道这个订单属于哪个用户了呀,那那他们这个关系是不是就能保存下来是这样的啊,这是关于一对多,那多对一是不是应该是一样的效果呀,那不再多说了,那现在关键是咱们这种多对多的关系,我们一般是怎么去做的?啊,你看这张表和这张表显然就是多对多的关系,对吧,那这个怎么办。咱们也加外键行吗?哎,好像就不行了啊啊不行了,为什么,你想想啊,假如说我这个在商品表当中,我加一个什么,加一个SKU,就是商品表的在订单表里啊,订单表里我加一个商品表的外验。
06:08
那相当于一个订单里面是不是可有多多种商品啊,对不对,那你也就是你一个字段当中是不是需要存多个商品的ID,对不对,那这个首先就满就就违反了我们关型数据库设计当中的第一个这个范式要求啊,就是这个字段属性,哎,不可分割啊,那相当已经不是原子性的了啊,这个肯定不行啊,肯定不行啊,不能这么设计,那这种多对多的关系,咱们一般是怎么做的呀?啊是上加中间表。啊,中间表,谁是中间表?其实在这儿咱们订单详情表相当于就充当了那个中间表啊,它就相当于充当中间表了啊这个怎么去理解啊,怎么理解啊,这张表你就可以把它当成什么呀,这张本就是专门用来存储订单和商品之间的这个关系的表,那怎么理解啊?来我们订单详细表当中很重要的两个字段是哪两个呢?一个是order ID。
07:02
一个是什么呀?一个是s AK ID or DR啊来想一想,我的一个订单当中啊,我是不是可能有多件商品啊,比如说我现在这个订单的ID是1001ID,这是我的订单ID啊,那我商品呢,比如说我A商品啊,买了一个B商品买了俩,然后C商品呢,买了仨,对不对,这是我的一个订单啊,那你这个订单下完之后,你会在哪会在详情表当中是不是插入几行数据?三行对吧,那这三行数据分别是什么样的呀?应是1OID就是1001,然后呢,商品A商品,然后呢1001,然后B商品1001,然后C商品,你看这张表当中是不是就存储下来了订单和商品之间的关系啊,对不对,那这就是咱们解决多对多关系的一个一个经典的一个措施啊,就加中间表啊,是这样的啊,那其实这个所谓的加中间表的过程啊,其实他做的是一个转换,将什么呀,将这两张表的这个多对多的关系转换成什么呀。
08:07
转换成两个一对多的关系,刚才咱们分析了这个表跟这个表是不是一对多,这个表跟这个表是不是也是一对多,是这样的啊,就是这个东西大家自己琢磨琢磨就行啊,这些都是咱们呃从事这个呃加E开发的时候的这个设数据库设计当中的一些讲话知识点啊,咱们在这儿呢,主要是以了解为主啊为主,行,那现在我们大致把这个咱们下单的这个几张核心表给大家捋清了,就是每张表里边存储什么数据,然后每张表跟每张表之间的关系什么样的,咱们已经搞清楚了,行,那这个完之后呢,那咱们接下来再给它进行一些扩展啊,大家来看我们这个订单表啊,还跟其他的一些表也有关联,比如说谁,比如说咱们这个省份表跟地区表。啊,省份地区,那这个相当于什么呀,相当于是我们这个订单是哪个省份的下的对吧,那你这个省份呢,它属于哪一个地区,比如说河北省,我属于华北地区对吧?哎,那是不是省份表跟地区表也是有关联的呀,那再问一下,你说这两张表应该是啥关系啊。
09:07
啥关系啊,肯定是一对多对吧?啊,华北地区我可能有很多省,对不对啊,是这样的啊,所以一对多啊,搞清楚就行,行,那这就是,呃,咱们这个订单当中的涉及到的另外两个表,就是省份和地区啊,那看还有什么,还有这个位置,你看这儿还有一个什么,这个编码字典表对吧?编码字典表跟这个订单表他们也有一个关系啊,这个为什么?因为里边是不是存储了那个订单状态的一些解释啊,对不对啊,这个大家应该也能知道,行了,接着往下走,这会还有一张表啊,这张表还记得吗?叫做older state log订单状态流水表,这张表里是不是记录了咱们所有订单的所有状态啊,对不对,是这样的啊,那所以它可能也是关联的。啊行,那接下来咱们再继续扩展啊,再续扩展订单这块还没完呢,咱们前面跟订单相关的还有一个表叫做活动,诶订单关联表对吧?啊,那这张表里记录了什么?记录了我订单和活动的这个关联关系,对吧?比如说某订单参与了某活动,那我就会在这张表里插入一条数据,那这张表里啊,它这个主要的这个字段应该是啥呀,是不是就是order ID和。
10:16
活动ID啊,对不对,是这样的,它相当于也是一个中间表啊,一个中间表行,那这个相当于我们这次差不多呀,就把这个活动把订单相关的表咱们就说完了啊,终于说完了太多了,对吧?啊好,那接下来咱们继续往下进行,咱们换一个业务,换一个换什么业务呢?换一个支付业务。啊支付呃,下单支付嘛,对吧,那支付大家来看一下这张表相对业务比较简单啊,我们支付业务呢,就一张表啊,然后大家要注意了哈,我们支付的时候,你想一想,支付的时候是不是一般就调用咱们第三方接口了,对吧?那你想一想我那个第三方支付接口,人家关心你买什么东西了嘛,根本就不关心,人家只关心你花了多少钱,而不关心你到底买了什么,对吧?那所以说你看我们的支付流水表,诶,跟我们的商品有直接的关系吗?没有啊,是没有直接关系的啊,那所以说我们支付信息呢,直接对标的是我们的订单。
11:12
啊,当然呢,我们支付信息跟咱们用户有没有关系啊,肯定是有关系的啊,咱咱们得知是哪个用户就是支付了呃,多少钱对吧?那这个怎样没有直接画出来,但是即便没有画出来,我是不是可以通过这个表也能关联上啊对不对,因为它不是关系的,都是通的嘛,是这样的啊啊那这块咱们相当于把这个支付流水表说完了,那接下来咱们再继续往下进行啊,这个下单完了,支付完了,那还有什么呀,还有加购物车对吧?啊加购车,那咱们去看一看加购,那加购车咱们一张核心的表就是这个啊,那这张表关联的字字段应该是关联的表应该哪些呀?哎,首先咱们得道是哪个用户把什么商品加到了购物车里,对不对,那所以是关联商呗,啊,那家下边是关于这个收藏吧,咱们看一下收藏,那收藏这边是不是也应该关,这就是收藏的这核心表叫做favorite favorite喜欢收藏的意思啊,那他应该是跟谁关联呢?也是用户和商品,咱们得知道是哪个用户收藏了哪件商品,诶这样一个。
12:12
好,那再继续啊,这还有一个什么评论表对吧,那对于评论表来说呢,咱们得知道什么是哪个用户啊,评论了哪个订单当中,因为是不是评论是订单里边的商品呀,对吧,哪个订单当中的哪件商品,那就这么关联上了。啊,这是关于评论,那接下来呢,我们再去找一个另外的业务,还有什么业务,还有一个退单对吧,退单,那退单在这呢。退单在这叫做order refund info,那对于退单来说呀,因为我们知道的是什么信息,我们得知道是哪个用户啊,然后呢,他退了哪个订单当中的哪件商品啊,其实就这样一个关系嘛,啊是这样,这是咱们退单的这个业务,好,那接下来我们还有最后一个诶这个业务啊来我们看一下优惠券领用表啊,优优惠券领用,这个领用呢,其实里边有两个概念,一个是领取,一个是使用啊,一个是领取一个使用啊是这样的啊,那这里边相当于咱们得知道啊,得知道什么,是哪个用户领取了哪个优惠券,然后他是不是有可能使用啊,然后呢,在哪个订单当中使用的这个券。
13:22
对不对啊,是这样的一个关系啊,那现在问大家一下,假如说啊,假如说啊,我用户领了这个券了,但是现在没使用,如果没使用的话,那它的OAD应该是什么样的。闹呗,对吧,因为没使用的,没使用是不是跟订单还没有关联呢,那准闹,只要你下单了,那那个哎在哪个订单下的呃,用的这个券那个ID就会变成对应的订单啊是这样的啊啊这是咱们领领领取优惠券这个业务,那其实到现在为止啊,我们这些业务大致就已经捋顺了,其实这这些东西你就按照业务去捋,其实还是很清楚的啊,还是很清晰的啊啊当完之后呢,我们再把一些那个描述信息咱们去捋一捋啊,你像刚才我们提到了商品表对吧,但是跟商品表相关的一大块一大块,你看这些表有什么,哎,三级分类,二级分类,一级分类啊,PU表这个品牌表,那这些表相当于都是啥呀,都是对咱们这个商品的描述信息,对吧?啊,我们观型设计,我们观型数据库呢,我们在设计的时候呢,我们有相应的规范啊,我们会使用这个三份式来去规范咱们这个表啊,三份式呢,大家可能不清楚啊,没关系,这个后续咱们会讲的啊,但是大家得知道这个三份。
14:35
它的目标是什么啊,我们使用三分式啊去设计数据库,那最终的目标是能够降低数据的冗余性啊,降低数据冗余性,那当然降低数据容易性的这个代价就是什么呀,我们就会将这个表啊,你会发现经过三分之后呢,你这个表会被最终拆分成很多表,那其实大家想一想,如果让你去设计这个商品表,你完全可以怎么样,完全可以把这些所有的描述信息都怎么样啊,是不是都放在一张表里啊,对吧,都放在一张表里,但是这里边呢,可能会有很多信息进行会会有冗余啊,那使用三分之后呢,这个表就会被拆开,就被拆成这种啊,是这样,这是我们关型数据库的特点啊。
15:14
好,这是关于商品的描述信息,那现在还有谁啊,比如说还有咱们的那个跟活动相关的信息,这是活动信息表对吧?啊,那活动信息表,那这里边我们跟他相关的有一个活动规则表啊,这里边儿包含了这个满多少减多少啊,那这个是什么呢?是参与该活动的商品都有哪些啊,也相当于是对活动规则的一个描述。啊,然后这个活动啊,有些活动是不是需要用券啊,有些活动不需要用券对不对,那需要用券的话呢,那我还得跟对应的券关联一下啊,是这样的啊好,那这个其实差不多就是我们整个的电商这个表结构了啊,差不多就是这些啊,那完了之后呢,我把这个视频录一下啊。
我来说两句