00:00
好,那现在我们开始熟悉业务数据库的第三步啊,那就是结合具体的业务过程去分析数据的变化啊。那我们要想结合具体的业务过程去分析,那是不是就得先将与每个业务相关联的表关联起来,对吧?啊,比如说我们得知道与订单这个业务相关的表都有哪些,对吧?那这样一来,我们才能知道一个订单从它开始到完成啊,整个过程当中到底有哪些表的数据会发生变化,以及发生什么样的变化。对吧啊,同时啊,将各业务相关联的表关联起来啊,这个有助于我们去理解业务啊,那关联表啊,最直观的方式就是画图对吧啊。然后大家呢,其实可以借助一些数据库的设计工具去画图啊,比如说我们文档后边呢,提到了一个设计工具叫做e zd ML,我们可以找一下在这个位置啊,就是这款啊,像这些数据库的设计工具呢,它能够提高我们的效率啊,那在这儿呢,我就先不带大家去画这个表关系图了啊,我文档当中呢,已经有现成的了,我们去找一下啊,就在这个位置啊,大家来看啊,这儿一共有两个图对吧?那一个是电商业务表啊,那下面呢,还有一个是后台管理系统相关的表。
01:13
那这个电商业务呢,其实主要就是大家所熟悉的加购啊,下单支付,退单退款等等等等啊,那这个图里边呢,所展示的就是与这些业务相关的表啊,那这个后台管理系统呢,大家可能就不是那么熟悉了,对吧?啊,因为后台管理系统呢,那通常是只开放给我们公司内部的运营人员去使用的,那这个后台管理系统的管理的主要是哪些内容呢?诶,其实主要就是商品啊,哎,什么促销活动啊哎,优惠券啊等等等等,主要是这些信息啊,那例如我们要上架一款新的商品啊,或者说去推送一个新的促销活动等等等等,诶都得在这个后台管理系统上面去做啊,啊那这个电商业务相关的表啊,相对来说更加复杂哎,也更加重要啊,那这个后台管理系统相关的表呢,要简单一些啊,那所以现在呢,我们先重点看一下电商业务表啊来,我们把这个PPT打开。
02:12
好,我们一起来看一下啊,这个图看起来有点乱对吧?啊,因为我们刚才提到了啊,就是这个图里面呢,哎,它包含了与加购与下单,与支付,与退单与退款等等等等这些业务相关的所有表,对吧?啊,所以说呢,看起来是比较乱的啊好,那现在呢,我们先看第一个业务。那第一个业务是什么?是收藏业务对不对啊,咱们简单看一下这个与之相关的表就行了啊,一会儿我一会儿我们挑一个最重要的业务去分析它这个数据的变化啊来咱们先看这个啊,那与收藏相关的表其实就这样的三张,那分别是啥呀?是不是用户表,还有啥,还有收藏表,那还有啥SKU商品信息表,其实这里面最核心的一张表应该是谁呀?是不是就这张表对吧?那这张表里最核心的两个字段其实应该就是谁啊,用户ID加上SKUID没错吧,是不是只要有了对应的SKU,有了对应的userr,我就知道这个人跟这个商品之间是有一个关系的,对吧?什么关系?那就是收藏关系呗,啊,其实就是这么简单啊,就这么简单啊,OK,那完之后我再多问一句啊,大家说用户表跟商品表之间,它俩应该是什么关系啊?
03:22
就是从收藏这个业务来说。是一对一啊,一对多还是多对多对到底什么问题?显然是多对多呀,对吧,你想啊,我一个用户是不是可能收藏多个商品对吧?那一个商品是不是可能被多个用户收藏,那显然多得多,那通常情况下咱们去解决关型数据库里边多对多的关系啊,都是怎么做呀。到时候怎么做,是不是就是建一个中间表对不对,中间表里边就是俩核心字段,一个是这张表的ID,一个呢是这张表的ID,没错吧,那是不是通过它就能把这个多对多的关系表示出来,那所以说这个表其实就是相当于我们解决多对多关系里边的那个中间表对不对?
04:03
是这个道理吧,其实就这么一回事儿啊,其实不难啊,好,接来我们继续往下看啊,看下一个表,那下一个业务,下一又是加购车业务,对不对?那加购车业务呢,其实跟刚才没啥区别对不对?只不过表变了一下对吧?原来我是在这张表里去计算用户和商品之间的关系,那现在呢?诶,我用这张表去记录用户跟商品之间的关系,没错,因为加购物车无非就是哪个用户把哪个商品加到购物车里边了呗,是这个道理吧?啊,那这就是购物车表啊,接下来我们继续往下走啊,那这个呢,是优惠券领用表啊,其实也是一样的道理啊,一个用户是不是可以领多个券,那一个券是不是可能被多个用户领?没错吧?啊,那在这儿呢,所以说中间来一个优惠券领用表啊,库房柚子啊,好,我们继续往下看啊,那下边这是与订单相关的表,对吧?与订单相关的表就比较多了,对吧?这一大片全是跟订单相关的啊,那咱接下来呢,就重点分析一下这个下单业务,因为下单业务是不是我们整个这个电商当中最重要的一个业务啊,对吧?我们首先先来看一下啊,就是与下单相关的表都。
05:03
大些来一个一个看啊,先看这个。是不是U表这个不用多说,对不对,那接下来下一个。Older info没错吧,这里边是不是存储了所有的订单啊,OK,那大家能看到older info里边呢?诶,是不是会有一个UID去关联下单的用户啊啊,OK,那继续,那这里边还会有一个字段,它关联的谁?是不是关联了省份表,那省份表是不是又关联的地区表对不对?那这个记录是啥呀?相当于记录的下单的地区对不对,下单地址啊好,然后再往下走,这还有一个啥订单状态流水表,诶,大家还记得这个表里存的是啥吗?是所有订单的所有状态以及对应的时间对不对啊OK,那它会关联订单表来接下来继续往下走,这儿会有一个订单明细order detail,这张表里存的是每个订单里边的具体的商品项对不对?好,我们继续往下走,看这。这啥是商品信息表,没错吧?那订单明细是必须得关联到咱们的商品表才能知道这个商品的具体信息,没吧?那继续往下走啊,看一下这一部分内容。
06:07
这文件水平是啥?先看下边啊,下边这是啥?是不是优惠券信息表,这个呢?是不是活动规则表,没错吧?那我们的订单明细是不是会参与活动或者是使用优惠券,没错吧?那这两张表当中存在就是啥呀?是不是就是订单明细与优惠券的关联表,呃,这个关联关系以及订单明细与活动规则的关联关系?是这个道理吧,啊,就是这样的,那这样一来我们是不是就能够知道到底哪个订单明细参与了哪个活动,或者是使用了哪个优惠券了呀?是这个道理吧?OK,那这就是我们与订单相关的所有的表,好,那我们继续看下一个业务啊,那下一个业务呢是支付业务啊,那与支付业务相关的表呢,有户表userf啊,订单表F以及付paymentf啊,这个支付业务呢,其实比较简单,对吧?对于支付来说,我们要保存的无非就是哪个用户啊,它支付了哪个订单,好,那我们继续往下看啊,那再往下呢,是退单业务啊来看一下与退单业务相关的表都有啥啊,首先哎用户表啊,那之后呢是订单表,然后再往下是退单表啊,最后一个呢,是商品信息表s in啊,那对于退单业务来说啊,我们要保存的应该就是啥呀。
07:26
是不是哪个用户啊,他退回了哪个订单当中的哪个商品。没错吧,啊,这个其实也不难理解啊,好,那我们继续往下看啊,下一个呢,是退款业务啊,那我们也是先来看一下与退款业务相关的表都有啥啊,首先是订单表order info,退款表refund payment,那最后一个呢是商品信息表Su。啊,那实际上啊,与退款相关的应该还有谁,是因为还有用户表啊,对吧?但是退款表呢,在这儿并没有直接去关联用户表,而是怎么关联的,是不是通过订单表去间接关联的用户表啊,OK,那这就是与退款业务相关的几张表啊,啊,我们继续往下看啊,那再往下呢,就是评价业务了啊,与评价业务相关的表示都有谁呢?我们来看一下,首先第一个用户表user info,订单表order info,评价表comment info,那还有一个呢,是商品信息。
08:22
啊,那实际上评价业务要记录的信息就是啥。是不是哪个用户啊,他评了个单当中的哪个商品。没错吧,啊好,那我们继续啊,那再往下呢就没有了啊,那现在呢,我们就已经看完了与每个业务相关的表了,对吧?啊,那我们要想再更加深入的去理解数据啊,就必须得结合具体的业务过程去观察这个数据的变化了,那由于我们这个业务比较多啊,所以在这儿我就不带大家逐个去分析了啊,那我一会儿呢,会挑几个比较重要的,比较典型的业务带大家去看一下啊,然后大家在掌握这个方法之后呢,再自己去把剩余的业务分析一下。
09:02
好,那我们现在先看谁呢?先看下单啊,因为下单这个业务是咱们最重要,也是相对来说最复杂的一个业务,对吧?啊好,首先咱们从下单开始,咱们模拟一个下单的过程,对不对啊,首先我下单啊,我现在下单,那比如说张三啊,这个人啊,他下了一个单啊,那这个订单呢,里边一共有这样的三个商品项,分别是一商品,二商品,三商品,那买的件数呢,分别是一个两个,然后呢,这个三个是不是一共买了这样的三个商品,下了一个单,对吧?那下这个单之后,这些表哪些表的数据会发生变化。来一个来啊,首先用户表会变吗?不会,你不能说我下个单多了个用户,对吧?这肯定是不对的啊,那接下来下哪个会变?订单表肯定会发生变化,它会插入,他会新增一条数据,对吧,对吧,没错吧,一条啊,新增一条数据,OK,那还有谁会变订单状态流水表会不会变,会不会会变,因为这里边会存储所有状态,对不对?那包不包括刚下单,也就是未支付的状态呢?肯定包括,那所以这张表里也会写入数据啊,那这张表里写入几条数据呢?我给大家解释一下啊,这张表的表结构咱们刚才没看对不对,那现在咱们也不去看了,我告诉大家这个表结构什么样的,这张表的表结构是这样的啊,它的每行数据是一个订单的一个状态。
10:20
能理解吧,也就是只要有一个订单发生状态发生变化,那这张表里就会新增是不是一条数据,能理解吧?啊是这样的啊,那就是这张表是不是也会插入一条数据,好,我们继续往下走,那还有谁会变?订单明细是不是也会变,那它是不是会写入三条数据对吧?一行数据是一个订单明细,一个商品项嘛,三个三个商品,三条数据,好,那还有谁会变?下边先看一下这个省份表吧,他俩会变吗?这肯定不会变啊,这个不用多说,那商品呢,也不会对吧?啊不能说我下下个单,这个商品,这个增加商品,这不可能啊,他也没有,那完了之后呢,看这几张表,那首先优惠券信息表跟活动规则表肯定是不会发生变化的,对不对?那关键是这两张表它会不会变。
11:02
他俩会不会变取决于什么?对,取决于我这个订单他有没有参与活动,或者有没有用券,对吧?如果我参与活动了,那是不是这张表里会变化,会插入数据啊,对吧?啊那当然,那如果我用券呢,那这张表里是不是就会插入数据对吧?反之呢,如果我没用没用没用券,没有没有没有参与活动,那他们会变吗?是不会发生变化的,能理解吧,诶这个呢,就是咱们,呃这个下单的一个操作,我下单之后是不是这些表的数据会发生变化呀,那接下来我们就来进行啊,下完单之后,这个订单是不是会有一个周期性的变化过程,对吧?我下完单之后我会干啥,是不是会支付啊,对吧?那接下来我先来到第二个阶段,我要支付了。诶,我要支付了对吧,那我要支付的时候,那哪些表会发生变化呀,那首先用户表不会变对吧,那订单状态流水表会不会变,肯定是会发生变化的啊好了,这个怎么变。变大了,哎呀,完了这回不去了啊,那我撤一下就就全没了啊,咱们俩接着走吧,没事啊,那我们现在是不是要支付了呀,对吧,那支付了之后,刚才说了这个表会发生变化对不对,那它里边哪个字段会变。
12:07
Order状态那个字段会变,对吧?那还有谁会变oper opera time那个操作时间是会变,会变成支付时间对吧?那还有谁会变?这张表里是不是会插入一条这个支付的状态呀,没错吧,诶,它会发生变化啊,那还有谁会发生变化呀?订单明细会变吗?是不是会变的,那下边会变吗?都不会变化对吧,也就是状态变,是不是只有他俩会变呀,对不对啊,那当然呢,诶支付表也会变,但是支付表上的它它属于另一个业务,属于支付业务了,对吧?啊,因为你支付的是不是支付表里会多一个支付记录,没错吧,但是它不属于咱们订单业务的表,咱就不看它了啊好,那接下来我们继续,那下边我的订单状态还会发生很多次变化,对不对啊,那发生变化变化,一直变化一直变化,那那这两张表是不是就会一直变化对不对,那直到什么时候这个数据就不会再发生变化了呢?这个订单完成了就不会发生变化了,那这个订单什么叫做完成了呀,这个对这个订单的完成标志其实很多,对不对,我首先第一个我假如我下单之后啊,我直接取消了,这是不是就完成了,对不对,它是不是也不会变了呀,对吧?那或者说我超时了,自动取消是不是也就完成了,对不?还有什么呢?啊,比如说我确认收货,确认收货叫不叫不叫完成,确认收货不叫完成,为啥呀?对,因为你确认收货之后,是不是还可能会申请退款呀,对吧?啊,那这个是不是说明订单还会变化,这说明没有完成,对不对啊,那什么时候叫叫做完成的呢?一般情况是这样的啊,如果你确认收货之后一定时间之内没有发起退款,这个是不是就是会完成啊,相当于对吧,那当然一段时间不同的,呃平台有不同的标准,有可有七天的,有15天的,有30天的,对吧?诶不同平台有不同标准啊,这个理解一下,或者还还要怎么叫做完成啊,啊比如说我申请退款,并且退款完成了,这是不是也叫呃完成了呀,对吧。
13:57
是这样,这就是订单的完成标志,只有到了这样的几个标志之后,咱们这个订单的数据才会就相当于不会发生变化了,这个要理解一下啊,好,这就是与哎咱们下单相关的这个业务的数据表的变化就这么变啊,这个大家有所体会了吧,应该啊,应该有所体会了啊好,那为了让大家体会的更深一点啊,我们再来看一个业务,看一个优惠券零用业务,这个业务也比较简单,其实它比较简单,咱们来看一下是不是一共就这样几张表啊对不对,那有什么用户表,有优惠券零用表,有什么优惠券信息表对吧?啊,那接下来呢,我们去看一下这个表的数据是如何发生变化的,呃,刚才这个优惠券领用表的表结构咱是不是也没看,我们没有看它的行,也没有看它的列,对不对,那现在这样,咱们就看着这张表去说啊,那咱们找到优惠券领的表,我们再讲这一个业务啊。
14:44
好,这个呢,就是优惠券领用表的这个核心业务表,对吧,那刚才我们看到的什么用户表和优惠券表,在我们用户领券的时候会变吗。这两张表是不是会变的对吧?其实变主要是这张表变没错吧?好,那接下来我们就来模拟一下这个这个这个领券的业务过程啊来在模拟之前我们先熟悉一下这张表的表结构,首先我们先看它的每行数据是什么,应该是啥,是一个用户对一个优惠券的领取记录,领用记录没错吧?啊看是不是谁领了哪个券啊对吧,能理解吧?啊好,那接下来我们我们再来看它的列啊,就是字段啊,首先第一个啊,ID这个其实就是领用ID,这个就是一个编号,那接下来往下看。
15:23
优ID是不是就用户优惠券ID就是用就是优惠券对吧?谁领的谁咱得知道,好接来往下走,下边这是不是有一个order ID,订单ID,那这是啥意思?是不是哪个订单用了这个券了呀,对吧?好,那就来继续。下边还有一个coup房status是不是购物圈的状态对吧?那这里边呢,有未使用的状态,有使用中,有已使有已使用的状态等等等等,好接来继续,下边呢,有三个时间啊,四个啊四个分别是啥呢?一一起来看一下啊第一个字段是啥获获取时间,其实就是领取时间对不对?那下边呢,Use time,那还有一个是use time,那这俩好像都是使用对不对?那这俩使用指的分别是啥?给大家解释一下啊,这个U静time呢,其实相当于是使用中的时间对不对?什么叫使用中啊,对于优件领域来说啊,就是我下单了,但是还没有支付,这个状态是不是叫做使用中的状态啊,诶咱们理解一下就行啊,这是use ta,那use ta呢,就是你支付完了,这是真正的用了,对吧?哎,会有一个对应的use这个。
16:24
相当于就是支付时间,那它相当于就是下单时间呗,对吧,下单时间支付时间没错吧,好继续下一个,这还有一个啥,是不是过期时间SPA time对吧?那假如用用户领券之后我一直都不用,那最终是不是会过期啊对吧?那这个就是它过期的时间spare time OK,那这个表结构咱们说完了,接下来呢,我们来看一看啊,这个咱们用户在领券的时候,这个表到底是怎么变的?诶我们来模拟一个领券的场景啊,像第一步是不是会有一个人他领一个券啊对吧?那这时候这张表里会怎么样。是不是会插入一条新的数据,对不对?那这个新数据分别是什么样的,咱们来看一下啊,这里边会有一个唯一的ID,这个是没问题的,那U的ID会有值对吧?就是呃,领取的那个用户的ID,那这个呢,是不是领券的券的ID啊对吧?那再往下这一个order ID,这是啥?是不是对应的订单ID对吧?那现在它有值吗?没有,你刚领的时候还没用呢,对吧?所以没有值,所以是no对吧?那库房LIS呢?那是不是未使用的状态对吧?那继续往下走,Get time有没有,有就是领取时间,那下边呢,都没用,都没用,是不是都是no,没错吧,这个搞清楚啊,过期不不,这个过期时间在这只是这样的啊,就是到它过期的时候这块才会有值,一开始时候也是闹啊,就存储的就是它真正过期的那个时间,能理解吧,能理解一下,好接在我们继续往下进行吧,那再往下呢,还有啥。
17:44
再往下是不是就是我得进入到下一步了,对吧?用户是不是用需要用券去下单了呀,对吧?那接下来用户用券下单,那看一看这个数据会怎么变啊,首先会不会新增一条数据,不会,还是这条数据只不会发生变化对吧?这要搞清楚变,那哪块会变呢?ID不变,Coupon ID user ID都不变,对吧?订单ID会不会变,这会出现一个对应的订单ID,没错吧,下一个coons呢,会变成使用中的状态啊,使用中的状态啊,接下来继续,那下边会有一个get a time,这个会不会变,不会变还是原来的值对吧?那现在是不是有一个下单时间了,那using time,也就是下单时间是不是就有了,没错吧,那下边呢,它俩同样是没有,还是闹对吧?那我们继续,那下面是不是会支付啊,对吧,那支付的时候是谁会变啊,是不是状态会变,支付时间会变,其余不会变。
18:32
没错吧,啊,那我使用它支付之后,那你说我这个领用的业务是不是就是结束了呀,是这个道理吧,就已经结束了啊OK,那当然了,我这个业务结束还有另外的标志。啥标值啊对过期对吧,比如我领了之后,我一直不用,一直不用,是不是最终过期时间会出现一个值啊,对吧,就这样了,那这就是优惠券领用表啊,这优惠券领用表啊,OK,那优惠券领用这个业务咱是不是也过了一下相当于对吧?啊OK,那其余的业务呢,我就不再大家一个一个去看了啊,其实有的业务它比较简单啊,什么样的业务简单啊。
19:08
如果这个业务表的数据啊不会发生变化,那这个业务肯定就是简单的啊,怎么去理解啊,你像我们刚才讲的这个订单,还有优惠券领用,是不是这个数据都会发生变化,对吧?它的业务是一个周期性的,对吧?从开始到最后是不是中间要经历几步啊,对吧?那这样的业务是比较麻烦的,它的数据变化也是比较复杂的,但是有些业务它的数据只要写进去就不会再发生变化了,这种业务比较简单,谁比较简单呢?举个例子啊,咱们以谁为例呢?以这个评价为例,咱以评价为例,咱们找到评价表啊,评价在哪,在这。Co,那想一想啊,这个评价表,你说它里边存的是啥,是不是存价,存储的是我们的用户对一个订单里边一个商品项的评价呀,对吧,你想啊,通常情况下我们的有一些电视平台当中呢,咱们是有规定的,什么规定?就是评价是不能不能修改的,对吧,对吧,我已经给出评价之后,你还能改吗?是不能改,但是你可以怎么做呢?你可以追加对不对,但是你追加你相当于是啥,是不是一条新的评价,没错吧,那也就是你像这种业务,他的数据只会怎么样,只会新增对吧?就是用户评价商品,就往这张表里写一条数据,那就完事了,是不是就结束了,就不会再有后续的步骤了,能理解吧?诶这就是,诶这种不变的业务,你像这种不变的业务都比较简单啊,会发生变化的业务要复杂一些,好,那业务表呢,我们就先说这么多啊,那接下来呢,我们再去看一下与后台管理系统相关的那几张表啊好,我们找到表关系图啊,来打开这个PPT。
20:37
刚才我们已经提到了啊,我们说后台管理系统呢,管理的主要就是一些商品信息啊,活动信息以及优惠券信息等等等等,对吧?啊,那现在我们来看一下啊,首先我们先看第一部分啊,第一部分呢,是与商品相关的所有的表,对吧?诶你会发现啊,这里边大部分的表都是与商品相关的,对吧?那其实对于一个电商平台来说啊,这个商品是非常非常重要的,好,那我们现在先看最核心的一张表啊,就是SKU。
21:06
对吧?那上边呢,是与之关联的P啊,那左边呢,是与之关联的,诶品牌表也就是base trademark对吧?那下边呢,诶就是123级分类表啊,然后呢,大家要稍微注意一下啊,这个三级分类表呢,是一次去进行关联的,这个怎么理解呢?大家可以看一下啊,是不是首先先使用SK in for与三级分类关联对吧?那三级分类呢,再与二级分类进行关联啊,那二级分类呢,再与一级分类表进行关联。啊,这个要注意一下啊,好,那右边呢,就是我们前面所提到的商品的平台属性和销售属性了啊,当然能看出来啊,我们的平台属性和销售属性啊,它的设计实际上是对称的。没错吧,是上下对称的啊,所以在这儿呢,其实我们诶,把一个理解了,把一个搞明白了,另一个也就搞明白了啊,现在呢,我们重点以平台属性为例进行讲解啊,那我们看一下这几张表啊,来我们先看第一张啊平台属性表啊,叫做贝斯at tr in for对吧?这张表我们前面讲到过啊,它里边存储的是什么内容?
22:09
是不是所有平台属性的属性名啊,对吧?啊,前面我们也说过啊,就是一个平台属性或者是一个销售属性呢,我们可以把它当做一个K值,对。没错吧?啊,那这个K所对应的就是啥?是不是就是属性名,那Y6呢,是不是就是属性值啊,对吧?啊好,那这张表当中存储的实际上就是所谓的K啊,OK,那我们再看下一张表,下张表呢,叫做平台属性值表贝斯atl y6对吧?那这张表里边存储的是不是就是所有的平台属性值,也就是我们刚刚提到的Y6,没错吧?啊,然后我们再来看一下这个表的关联关系啊,那首先大家注意观察这两张表是不是有一个关联关系啊。他俩为啥关联呀?啊,这个其实很简单啊,就是如果它俩不关联,我是不是就不知道这个属性值它到底是哪个属性的了呀,对吧,所以它俩是必须得关联的,好,那然后我们再看这啊,那这个平台属性表和三级分类表是不是也有一个关联关系啊,对吧,他俩为啥关联呀。
23:08
这个呢,我就需要给大家去解释一下了啊,那首先大家先回忆一下啊,我们什么时候才能看到这个平台属性啊。是不是当我们在首页进行分类检索的时候,才能看到这些平台属性啊,对不对啊,当我们在首页去指定任意一个三级分类的时候,后边是不是都会出现一大堆与之对应的平台属性和平台属性值啊?没错吧,那比如说在这儿呢,诶,我选中手机的三级分类,那后边是不是就会出现一大堆手机的平台属性对吧?那再比如说我这儿选中啊平板电视的这个三级分类,对吧?那后边是不是就会出现平板电视的平台属性啊,对不对?那我们应该能感觉出来啊,就是这个三级分类,它和平台属性之间必然是有关联关系的。没错吧,啊,那所以说那它俩是必须得关联上的啊,OK啊,那这就是这几张表的一个关联关系,好,那我们再来看一下这张表啊,这张表当中存储的是什么内容啊,这个前面咱们也说过了,对吧,它里边存储的是商品SKU平台属性之间的关联关系。
24:12
没错吧?啊,那这个关联关系又是怎么一回事呢?啊,这个我给大家解释一下啊,刚才我们提到了说我们在首页进行分类检索的时候,对吧?啊,那这里边当我们选中一个三级分类,那后边是不是会展现出一大堆的平台属性和平台属性值啊,对吧?啊那当我们啊,选中任意一个平台属性的任意一个属性值的时候,那下边是不是都会给我们展示出来一大堆的具体的SKU啊,对吧。没吧,那所以说SKU这个平台属性之间必然是有联系的。是这个道理吧,啊,OK,那这个联系存在哪呢?是不是就存储在这张表当中啊?好了,那这就是与平台属性相关的三张表,咱们就说完了啊好,那平台属性说完之后呢,我们再来看一下上边的销售属性,刚才提到了啊,销售属性跟平台属性它俩是对称的对吧?那所以说这个销售属性我们现在理解起来应该就比较容易了啊好,我们先看这张表啊,这张表呢叫做销售属性表对不对?其实这张表当中存储的就是所有的属性名,其实也就是K对吧。
25:19
啊,那同理,那这张表当中呢,是不是所有的销售属性值,那也就是我们刚刚提到的Y6 OK,那K与Y6之间是必须得有一个关联关系,这个不再解释了啊,完了之后我们再来看这个位置啊,大家注意观察啊,这个销售属性表与PU表是不是有一个关联关系,诶,那他俩为什么要关联呀?啊,其实这块的关联跟这儿的关联是同样的这个作用啊,给大家解释一下啊,那首先我们先明确一下啊,就是我们什么时候才能看到这个PU的销售属性啊,是不是只有当我们进入到一个PU的商品详情页的时候,才能够看到对应的销售属性啊。没错吧,啊,那而且我们不同的PU,它的销售属性是不一样的,比如说我一款手机的销售属性和一款笔记本电脑的销售属性是不是肯定是不一样的,没错吧?那所以说PU和销售属性表之间是必然得有一个关联关系。
26:17
啊,这个一定要注意一下啊好,那完之后呢,我们再来看一下这张表,这张表是啥?是SKU销售属性表,叫做SKUC at.Y6对吧,那这张表里的又是什么信息。啊,前面其实也说过了啊,那这张表当中存储的就是SKU销售属性之间的关联关系,那这个关系的作用又是啥呢?这个我也简单给大家解释一下吧,啊,那刚才我们提到了啊,说当我们进入到一个PU的商品详情页的时候,对吧?我们会看到一大堆的销售属性,以及后边对应的销售属性值,没错吧?那当我们选中任意一个销售属性的任意一个属性值的时候,是不是就会跳转到一个具体的SKU的页面,没错吧?那从这我们就能够看出来啊,就这个销售属性呢,与SKU之间是必须得有一个关联关系的,没错吧?那这个关联关系是不是就保存在这张表当中啊?
27:11
啊OK啊,那这个销售属性我们也就说完了啊,OK,那至此呢,诶,与商品相关的所有表我们就讲完了啊,那接下来我们继续往下看啊,那再往下呢,是与活动相关的表啊,这个活动相关的表是不是就少一些了,对吧?那我们简单看一下,那我们现在先看这张表啊,Activity啊,这其实是跟活动相关的一个核心表,对吧?啊,里边保存的是啥呀?是不是活动的基本信息,比如说什么活动的名称,活动的类型,活动的起时间和结束时间哎等等等等,好,那我们现在再看下一张表啊,下一个表呢,是活动规则表,那这张表里边存储的就是啥?是不是就是每一个活动的每一条规则呀,对吧?那活动规则跟活动信息表是不是必须得关联一下,要不然你是不是就不知道这个规则到底是哪个活动的了呀,对吧?啊好,我们继续往上走,那上面这张表是啥呀。
28:02
啊,这张表是不是叫做活动商品关联表啊,对不对,也就这张表当中存储的是活动与商品之间的关联关系,那这个关联关系的作用是啥呀?啊,其实很简单啊,在这儿是不是就相当于划定了一个活动的优惠范围啊,对吧?是不是通过这张表我们就能够看出来哪些商品是能够参与哪个活动的呀。没错吧,啊好,那这就是与活动相关的几张表啊OK,那接下来呢,我们再看下面一部分内容啊,那下面呢,是与优惠券相关的表啊,那首先我们先看第一张,第一张呢是coup胖in for优惠券信息表啊,那这张表当中呢,还存储了优惠券的基本信息,以及优惠券的一些优惠规则等等等等啊好,那我们再看下一张表,下一张表呢,是优惠券范围表啊,叫做库旁润质对吧?啊,那这张表它的作用啊,实际上跟我们刚刚所讲的活动商品关联表是类似的啊,那这个活动商品关联表的作用是不是就是划定一个活动的优惠范围啊,没错吧?啊,那这个优惠券范围表的作用其实就是划定优惠券的优惠范围啊,但是啊,你注意观察这个优惠券范围表啊,它所联的表是比较多,对这关联了信息表了表是不也了三类表。
29:20
没错吧,那这个我们应该怎么理解呢?它为什么会关联这么多的表啊,那这个呢,实际上是因为啊,咱的优惠券呢,是有不同的类型的啊,就优惠券呢,诶我可能会有品类券啊,也可能会有品牌券,也可能会有商品券,那如果是一个品类券对吧?那这个优惠券范围表关联的是不是应该就是三级分类表。对吧,那如果呢,它是一个品牌券啊,那这个范围表呢,关联的是不是应该就是品牌表啊,那如果呢,它是一个商品券,那它关联的是不是应该是PU信息表啊。没错吧,啊,OK,那这就是与优惠券相关的几张表,那至此我们后台管理系统相关的表就说完了,那整个电商系统数据库的表呢,也就说完了。
我来说两句