目录
数据库选型
这个mysql以前一直是在使用的，是一个开源数据库的一个工具，开源的数据库。那么后来是归给
这个oracle了。像这个oracle公司他们是以这个盈利为目的，所以在未来mysql，它很有可能会闭
源，一旦闭源了，那么我们就不能够免费去使用了。那么所以呢，mysql的创作者就开发了另外的
一个分支叫做这个MariaDB，也非常好用。如果说，一旦这个MySQL闭源了，那么你可以直接无
缝的切换到MariaDB，因为它自己的服务名，它的服务名就叫做MySQL，他们是一模一样的，相
当于是一个双胞胎兄弟。很多公司包括一些互联网大厂，还有国外的一些公司他们都已经是把数据
迁到了MariaDB。
Navicat数据导入
我们使用utf8mb4，我们在现在是移动互联网时代，手机上会有很多表情啊。如果你使用utf8那么
你在进行这个表情的一个保存的时候，它会报错，因为它的这个字符集是不一样的。所以我们要选
择这个，使用它的话，我们在使用这个手机端上的一些表情的时候，那么它是可以正常的保存到数
据库，并且也可以正常的展现出来的。
设计表
用户表
注：id需要采用字符串型，因为在未来，一旦我们数据量大了，我们会去做分布分表，做分布分表
的话，我们这个数据类型一定要是字符串。如果说你是使用的是自增的，那么就无法判定我们的一
个用户的独立性，唯一性了。
imooc_num与can_imooc_num_be_updated相对应，你有唯一的一个字符串，那么你是只可以修
改一次，这个一开始是允许的，一旦你进行修改之后，那么第二次第三次你就不能够去修改了，只
能去看。
bg_img这个是我们的一个背景图,就是在我们用户页面，在用户头上的下方会有一个背景图啊，
是可以上传的。
短视频表
vloger_id其实就是对应到用户表里面的一个用户。它与id是一个外键关联。是弱外键，就说我们两
张表虽然是加了这样的一个外键，但是呢，我们并没有去设置具体的一个外键啊，因为这是一个规
范啊，你加了物理外界的话，那么我们的这个可能会有一些问题，就是说我们的这个表查询。可能
会慢，另外你删除表也会有一些依赖他们的一个偶合度太大。
like_counts，comments_counts其实我们在这边虽然是这么写的话，但是呢，其实我们真正意义上
这两个其实是不会从数据库查的，我们都是从缓存里面去查，所以这两个字段其实是比较一种弱的
字段。
评论表
like_counts和我们在刚刚vlog的中的一个数值数量自增的也是一样的，他们是换汤不换药，这个我们都会通过去Radis去做是一种比较弱的存储。
粉丝表
有一个is_fan_friend_of_mine，判断这个粉丝是不是我的朋友？如果是成为朋友，则本表的双方此
字段都需要设置为一，如果有一人取关，则两边都需要设置为零，其中一条可能要去把数据给删
掉。
我点赞的短视频列表
它其实也是以多表关联的一个中间表用户，这两个如果说我是1001喜欢了3003这个视频。那么这
边字段就是1001，一个就是3003，做到一个关联两张表一起去查询携带这张表，就可以把相应的
数据都可以查询出来。