本模块功能有两个热点：最热和最新。

这里面牵扯到2个数据表，一个表是跟单个的小说详情有关系的，另外一个是更新的记录。一些同学的作品把这个最后一章放在小说详情表里去，是个不错的设计，查询的速度会更快一些，或者说效率更好一点。

具体到作品，有几个问题。

同学1

1 首先id用的bigInt，本身没有太大问题，但是在小说列表这个部分，不会有那么多的书籍。设计要有目标性，如果不是特别大，要做个预判，这个表在两年内或者三年内会不会达到这么一个层级上，大部分非流水表数据是不会达到bigint的。

2 数据库字段有两种写法，一种是用下划线，一种还是驼峰大小写来来做区分。都可以，但是在我们的实习里面，建议大家去用这个大小写。方便Spring去跟我们所做的实体做自动映射.

3 更新时间要注意一点，不见得这个更新时间就是这个小说最后的更新时间，也可能是status的变更时间。那最新更新的那个章节时间，需要有一个字段记录的时候，可以在这加1个latestupdatetime

4 下面接口一般来说我们有三个默认的（除了流水表）方法：Insert、update和loadById。就是说，你连业务模型是什么都不清楚的情况下，都可以直接写的默认方法。

Delete这个功能尤其是对toc的互联网业务，很少会提供。一般这是一个后台功能。

5 有的同学会用这种类似于PageHelper的东西进行分页，在我们在实习项目里面并不建议大家去使用,尤其在大公司里面不会用这种东西，因为它的性能不是那么好。但是很多外包公司会去用它，因为用起来比较简单，但同时也屏蔽了很复杂的实现。

6 一个问题是page和limit必然用不到Long类型，一个页面不可能有那么长。，如果单页都已经到了Long的长度，那它的分页就没什么意义了。

7 最主要的问题就是NovelQueryVo的实现，它的返回值变成参数和返回值两个部分去约束，在如果定了一个返回值的话，返回list就好了，

同学2

数据库的文档设计比较不到位，功能主键有缺失，比如要考虑是不是有些章节的信息。另外，正常的数据表要有四个字段id、Status、addtime和updatetime.

另外m注意几个小的规范问题：表名最好用大小写。这样在做Entity map映射的时候，是不用单独的去做注解。

同学3

1 数据表字段都是以大写字母开头的，这个是可以的，但是ID这个字段是小写。

2 接口部分，动员会小拿同学一直强调说一定要好好看官方demo，那是我们实习的格式。大家在公司去实习的时候，实际上都会有开发规范。三个默认方法，insert、update和loadById

3 分页方法有一个页行数，这个最好是把它设计成一个常量，放在放在controller层去掉用，而不是选择在service层。

另外有个小的问题，就说typ的值。一般来说在设计上，0是有一个特殊值，不要去考虑用0作为一个具体业务，比如说最热，最新可以从1开始。进一步，可以考虑去写一个type的一个枚举啊，所以一个枚举12标志好，然后在业务controller层，在用枚举来实现，非常好去阅读和维护。

4 设计数据库字段最好不要用下划线，而是用驼峰方式。这个是spring默认的格式，不用去做映射。

5 Int类型的长度有12位吗?这是一个比较关键的问题，11是上限。

6 订阅人数最好不要叫Number，万一后面业务还有什么观看人数之类的，这个字段就不好理解了。所以一般来说在考虑名字的时候有个概念，如果你是增加字段，那是没有问题的，因为现在业务是没有影响的。但如果你增加了字段，跟你现在字段是有冲突的事，或者是名称上是有一定的覆盖性，那就不好理解了。如果你到时候再改，那对业务的影响可能会比较大。