该设计文档对电影详情模块的基本信息模型和特色功能推评分、三推等功能进行了比较到位的设计。

其中，基本信息模型的固定分类和上映地区，使用的枚举的方式来进行参数传递。三推和演员等要素也用缩写ID的方式进行快速关联，减少数据的查询。

但是同时也存在一些问题：
1数据表的默认字段理解不到位，比如说status和删除字段实际上是重合字段。而且注意在计算机体系里面和数据库设计里面，0为非法态，1是正常态。那0就是删除的意思，没必要再增加一个标志删除的字段，也就是说，在进行语句查询的时候，直接加一个status ！=0就行

2数据库字段类型的设计也一定要谨慎，要言之有理。比如说自增的ID字段，使用int类型就可以，Big int的长度已经不是单表能够维护的了。那个不在正常的业务范围内，也没有必要去想到说要进行分库分表的事情，那个都属于架构师层级要做的事，就算大厂校招也没有这个要求。另外，对一般的业务，像createby字段是没有必要的，因为对大部分c端的业务来说是没有操作员的概念

3 在主表里，面对常用的关联字段ID进行缩写，可以提高查询效率，但是这种方案对使用场景是有要求的。比如说演员 ID，在这个场景下，是适合缩写，因为这里面是一个多对多的关系，一个电影可以有多个演员，一个演员也可以演多个电影。那用缩写就减少了一次关联查询。

但是像视频，他这用缩写实际上并不合适，因为他是多对一的关系，也就是一个电影，会有多个视频，但是一个视频就属于一个电影。那这种实际上应该在视频表里面，直接带上movie ID的字段。本来就是查询一次，缩写并没有提高效率

而且要注意，一般缩写说明它更新的少，比如说电影的演员和导演，基本上是固定的。但是像一个电影关联的视频或者图集的推荐实际上，后期可能会不断的通过运营去增加

开发文档官方版：
移动端：https://m.naoffer.com/intern/task/771
PC端：https://xiaozhao.vip/intern/task/detail/771

Java开发文档 评审视频：
移动端：https://m.naoffer.com/intern/review/477
PC端：https://xiaozhao.vip/intern/review/477