今天完成的任务：

一、把项目的数据表设计好

复盘项目，求学大作战总共8个数据表。

分别是user（用户表） sign（签到表）  article（文章表） video（视频表）  collection（收藏表）  teacher（老师表）   signature（关系表）  code（验证码表）

然后Service准备分为两部分

academy-eatchicken-User-Service

User    sign   collection   code   signature

academy-eatchicken-study-Service

article   video   teacher

问了超哥，分为几个Service应该按照模块来分，比如我有用户模块，视频模块，文章模块可以这样分，不能按照前台和后台来区分，这样不合理，而且数据表会重复产生。比如对于文章，前台也需要，后台也是需要的。

在Service中应该包含的是对这张表的增删改查，不管是前台和后台

二、方案评审

方案评审蒋欣益讲的，没啥问题，都是我们之前讨论过几次的。另外从方案评审里面也提醒了我，对于项目的设计是需要考虑到并发的问题，现在做复盘比较简单没有什么访问，但是在真正的项目里面是需要想到，如果很多人同时访问一个接口的时候，会产生什么影响，服务会不会挂掉。

三、讲小课堂

小课堂讲三范式，昨天日报写过了。然后有几个问题：

1.三范式在实际应用中会出现什么缺点呢,在实际应用中哪些情况适合三范式

3NF只是数据库表的一种规范，但并不是一个死的规定，在具体的情况下应该对应的根据需求去决定数据表应该怎么使用3NF，有时候为了数据表查询方便，还有数据库性能，可以适当的舍弃一些规定，允许有一些冗余。

2.如何理解“有时不得不违背第三范式”

因为在数据库建表的时候，需要考虑性能和查询的方便，还有一些问题，所以有时候不能死守3NF的规定。

3.原子性说一下

原子性就是不可以再去细分，比如一个字段是

签到-----签到时间-----连续签到时间。

这样签到下面还可以分，是肯定不可以的。

4.简单来说三范式解决了建表的什么痛点

解决了数据表建立的时候出现的一些数据冗余或者数据库操作的异常问题。

5.三范式和一对多的表关系有什么关系？感觉很像

3NF是数据表的一种规范，一对多的关系是表之间的关系，没有联系。

四、听老大讲课

明天计划：

明天计划学习公司框架使用。

接口文档

遇到问题：

怎么分Service有点问题，解决了。

收获：

完成了方案评审。