学生涉及到的东西--字段

签到记录表：--点击签到后，会生成一条记录；

记录id--

用户id--

逆袭豆总数量--基础数量加上每天获得的数量

签到总天数--签到表中该用户的总记录数；

最高连续签到天数--数字类型的；--判断--比较连续签到数和最高连续那个大存哪个；

签到状态；--签到和未签到

当天签到获得逆袭豆数量--解决，判断前一天获得的逆袭豆数量；

当前签到天数--解决，判断前一天的签到状态；

当前连续签到天数--判断？根据

签到逆袭豆获得个数--1天1颗，5天后每天5颗；每日签到获得的逆袭豆个数根据连续签到天数来进行确定；1-1；2-2；3-3；4-4；5-5；6--5；

一个月的签到状态；根据当前日期计算算出当前的月份，在用户点击签到模块总按钮后，将一个月的记录返回前端；

前一天签到状态--默认为0；如果签到后，将状态更改为1；

连续签到天数的判断--前一天签到状态为0，签到后签到天数变为1；前一天签到状态为1，签到后签到天数增加1；

最高签到天数判断--最高签到天数默认为1，当连续签到天数大于最高的时候，更改最高签到天数为连续签到天数；

逆袭豆获得的数量了判断--签到逆袭豆获得个数--1天1颗，5天后每天5颗；每日签到获得的逆袭豆个数根据连续签到天数来进行确定；1-1；2-2；3-3；4-4；5-5；6--5；

点击签到后，签到状态更改为签到--累积签到数加1--连续签到数加1--最高连续签到数(需要判断)--增加逆袭豆(判断逆袭豆增加的个数)

学生数据表：

用户id

创建时间

更新时间

创建人？

用户昵称

班级

逆袭豆--？这个跟签到表有重复，不写联表查的话就得有这个字段

区域

状态--冻结和不冻结

我的收藏分为文学部和影像部---！！这个是需要文学部和影响部的关联表。。

手机号

邮箱号

签到记录表：--在门卫处点击签到后，会生成一条记录；

id--

用户id--

创建时间

更新时间

逆袭豆总数量--基础数量加上每天获得的数量

签到总天数--签到表中该用户的总记录数；

最高连续签到天数--数字类型的；--判断--比较连续签到数和最高连续那个大存哪个；

签到状态；--签到和未签到

当天签到获得逆袭豆数量--解决，判断前一天获得的逆袭豆数量；

当前连续签到天数--判断？根据

文学部--文章列表

Id

创建时间

更新时间

创建人

文学部标题

封面图片链接

分类

作者

老师？？？--文学部看原型图没有老师这个字段，

摘要

详情

状态

被点赞数

被收藏数

学生表和文学部中间表

表id

创建时间

更新时间

创建人

学生id

文章id

收藏状态

点赞状态

影像部--视频列表

Id

创建时间

更新时间

创建人

年级

科目

视频所属老师

标题

分类

视频简介

视频链接

正文

被收藏数

被点赞数

学生表和影响部部中间表

表id

创建时间

更新时间

创建人

学生id

文章id

收藏状态

点赞状态

后台管理账户信息--权限user表

Id

创建时间

更新时间

创建人

用户名

密码

手机号

角色

？？用户角色表--userRole表--可以不用放中间表

用户id userid

角色id roleId

角色表--权限role表

表Id

创建时间

更新时间

创建人？

角色名

角色权限

角色权限表--role-permission表

角色id--roleid

权限id-permissionid

权限表--权限permission表

Id

创建时间

更新时间

权限名

权限描述

表具体使用的字段类型没有说明，字段长度也没有说明；--有一点疑问的地方就是存文章内容的时候，不知道是具体存文章类型为text还是别的什么，比方说放在服务器的某个文件夹里？网上看看优劣去。。图片可以直接引，没有问题，代理就行-文件没弄过，试下这块；

今天还和队友讨论了几波原型图，对这整个项目的理解加深了一些；

论坛和树洞其实自己想实现，到时候让pm帮我整个需求，如果team不要做的话，我自己实现下，想做做这个功能；

因为思考这个的时候，表的对应关系作用我捋顺了些，所以自己脑子里的论坛是这样---

论坛帖子一个实体表，评论一个实体表，论坛跟评论是一对多的关系，一个帖子多个评论，一个评论只能属于一帖子；那需要在每个评论加个字段说是哪个帖子的。。至于评论和恢复，都是算评论的一种，可以加一个字段区别下。。明天将这个表的字段弄下，网上找个论坛参考下；

建表的对应关系使用；

今天想了下---建表的时候，思考实体之间的对应关系一对多，多对多的用处，或者说对建表的帮助，算是有点眉目了。。之前也没细想

先说看有多少个实体，即需要建几张实体表--这个我是看原型图设计到增删改查就来一张实体表，每个模块一张表是最起码的；

判断是一对多还是多对多自己想的是这样，在实体表的字段确定后，判断a表的字段1和b表的字段2的关系很好判断，我这不细说了；

接着是一对一关系；如果表的两个字段是一对一，那么完全可以放在一个表中；

一对多的关系；一个表的字段，和另个一表的字段是一对多的关系，那么在多对应关系的那个表中，可以将一对应关系的字段填上就可以了；

多对多关系；因为表的主键字段的唯一性，所以一个表中的某个字段，只能是对应一个字段，当时多对对关系的时候，在中间表中，将两个表的主键字段，换成中间表的非主键字段，就实现了关系的连接。

我觉得这个算是思考一对多和多对多对建表帮助的最大的一部分，自己是以前有思考关系，但是没有将关系和建表联系起来。。联系起来就立马发现思考这个关系真的是用处太大了。

 下面的图示自己思考的一个签到的流程图；应该是比较完善的。。。但是没有思考在签到的时候，如果存在补签--一些网站为了冲会员什么的，会开放这个功能获得奖励--这个的逻辑还没有想一块去，没有这个需求这个可以先放一放，自己有时间的思考下，想好了mark一下。。

明天计划：等java队友提交任务，web队友提复盘申请，这两天就差不多了。。自己明天试着看能不能建表把签到的功能实现；其余的逻辑不多，基本是单表的增删改查；权限管理跟自己之前重构任务的管理差不多，难度不大；

如果写表的话，会将建好的表的结构再mark一下；