一，今天完成的事情

任务三1-3

1.查看垂伦小室的产品资料（PPT，原型图，禅道）

首先仔细看，理解需求。

任务3需要完成的是前台接口。网站模块几个，前台后台都看，才能理解。不知道作者每天希望或者预估每天访问的人数是多少，每人平均访问多少次。但是应该不多。

并且，因为是任务1,2的承接，所以还是选SSM（Spring+SpringMVC+MyBatis）完成此项目。

客户的要求都常见。同一个类有层级结构的有 导航栏，回复和评论，只算自己类目前此项目只有2层。我的代码可以扩展层数。有逻辑，逻辑最难的也只是算法middle难度。不同的递归，递归看情况，tree不搭配其它也算easy级别的算法。

游客不自动分配名称。

是前台。有的公司经常说“中台开发”。这不是指前端，不是指后端。

2，我现在看到的任务三要求2是：依据一对一，一对多，多对多的原则去拆解需求，理清实体表和关系表，依据需求设计DB，建立好索引，要求具备可拓展性（如当前设计导航为二级目录，当业务拓展为三级、四级目录时代码在不变更或者少量变更的情况下可继续使用），遵循Java编码规范，注意命名，并在本机建立好数据库，并对数据库的数据量做好预估。

为了达到工程目的，没有绝对的对和错。我看到有的帅哥美女字段和别人设计的不一样，被批评的挺惨的。可是能用最重要。考虑扩展，多设计1-n张表也不能算错。必须的字段不能少。但是多设计不一定必要的字段也不一定错。

我设计的表能满足本项目前台的要求。根据项目要求使用解决方案，当然有其它可以达到目的的方案。

数据库必修部分告知有6范式。不容易理解，但是只要是数据库的课程都会提。数据库理论，数据库基础，oracle，SQL server都提。

建议多看一对一关系。前台功能可能用到user 用户表，但是对于前台显示几乎无影响，所以没建立user表。

（1）一对一，一对多，多对多的原则去拆解需求，理清实体表和关系表

本项目我没使用多对多关系，所以没使用关系表。

我差点没注意工作室管理中上传图片可以上传多张，和其它实体不同，其它实体如果上传图片，每种类型的图片只有一张，所以直接属于那个实体。差点漏了一个一对多。

一对一：banner→作品（或者artworkUrl，后台原型图给的作品链接）。编辑人→工作室管理/工作室管理的图片/作品/banner/评论回复/导航栏。（编辑人应该就是user。）

一对多：工作室管理 →工作室管理的图片。作品 →评论。作品 →回复。评论→回复（应该没限制一条回复）。上级导航栏→下级导航栏。一/二级导航栏→作品。

如下图，我建立了art_room数据库。下图6张表从上到下代表：工作室管理，工作室管理的图片，作品，banner，评论回复，导航栏。

（2）索引

主键id是主键，肯定有主键索引。

如果根据先后排序，选用的是哪个字段，比如updated_at字段，在这个字段上建立了索引。

根据除了主键id是主键，如果需要常常查询其它id，也在其它id上建立了索引。比如

（3）不用外键。我一般不用外键。选用的策略都是根据实际的，一般不用外键。

（4）表设计。看后台设计，上传的时候如果值为空，前端有部分提醒。根据我看到的情况，设置可以不为null的值。我的status都使用int，这样能表示更多属性。加是否属性的时候可以不加列。int 有32位，可以有32种是否状态，直接数字扩展。需要的时候加一个status表来说明各种状态。

artstudio。数量不多可以不加主键外的索引

其中image_url，是使用的时候，从artstudio_image查询各图片url的情况进行组装。多图url用逗号隔开。展示图片数量我不Limit，因为上传的时候已经限制图片张数。每个artstudio可以有0-n张图。空就是没上传图。

artstudio_image。条目目前不大，可不用主键外的索引

artwork

数据量可能不小。二级导航的id经常会被查询，找到相应的作品。而且一般是新的放在前面，旧的放在后面，所以加上索引如下

banner

banner, artwork 和 artstudio都有 id 创建时间 修改时间 编辑人。是否显示。还都有图片。但是这3个总体的父，需要表示的状态差的有点远，后台管理的时候管理员是分开管理。所以还是分开3个类别。条目目前不大，可不用主键外的索引

comment_reply

这里也是status中，0是不展示。1是展示，并且1是别人的评论。作者的回复全部展示，所以给一个状态2表示作者管理员回复即可。

parent_id如果是art_work，那就是0。在artwork_id中已经知道是对应哪个作品。因为要组装作者回复给别人的评论，才需要再设置父id，就是别人评论的id。和status一起区分是评论，还是作者管理员回复。

经常查找这个表的artwork_id，来找到对应的评论回复。

通过updated_at从新到旧展示。

所以给这2个加上索引，如

manu

这个是我的导航表。上面的 评论回复 表的的评论回复经常增加，有时候减少，总之变化的可能比较大。而且条目很可能上万，比较多。

但是导航一般不会修改。条目也不会太多，每个上级条目包含的下级条目很少超过100条。总之是读多写少。所以我设置了children_ids字段，用逗号隔开下级id，null就是叶子节点。后端，前端处理都会更方便。虽然有parent_id，直接给前端，前端已经能处理。

数据量不大，一般直接根据id查所有属性，数据库一般用children_ids不用parent_id。不建立主键外索引

(5)数据库的数据量。

作者管理的条目不多，20条内，每个能上传若干（5个）图片，预计作者管理的图片100条内。

banner目前最多展示6个，有的暂时不展示，预计10条内。

导航栏，各级不多，预计100条内。

变数最大的是作者的作品。如果作者确定上架的作品是700，那artwork的数据量大概就是700。

留言对于每个作品限制展示50条，且不是每条留言都会被作者回复，也可能被作者回复多次，那留言和回复的数据量就算每个作品100。70000条。

每条数据各个字段，算长度。相加为每条。乘以预估数据条数。

3，

banner，作品集，作品集分类在后台原型图可以拖拽列表项来完成列表的重新排序，在后台管理按顺序显示。在相应表中，可能需要加order顺序这样的条目来记录顺序。但是前台展示是不是按这个order不明确。因为我只实现前台，没加这个字段。如果使用这个字段，数据库或者对象按照字段排序即可。

二，今天问题

况帅哥好。如果用接口生成工具，目前用哪个接口生成工具？现在看到的风格接近swagger。docway优秀。

有的前端喜欢我直接把接口的，传入，输出都直接用json写出，就是给假数据。而不是给类似如下风格的表格

三，今天的收获

复习数据库一对多，多对多，一对一。工程灵活使用。

banner，作品集，作品集分类在后台原型图可以拖拽列表项来完成列表的重新排序，在后台管理按顺序显示。在相应表中，可能需要加order顺序这样的条目来记录顺序。但是前台展示是不是按这个order不明确。因为我只实现前台，没加这个字段。

这个项目我没分模块。可能结合任务2说分模块。父子模块通信没问题就可以。

四，明天的计划

任务三 1-9