本作品基本上对电影详情模块的基本数据模型以及对应的逻辑属性的数据库设计比较到位

比如，在电影类型和地区用了枚举的方式，通过数字记录与字符型记录，更适合传输和数据统计。
另外，对常用字段的设计和类型比较到位。
包括本期特色的推剪辑和推图集的功能，以及导演和演员的展开，还是合病都有一定的考虑和设计。

但是存在以下几个问题：
1，数据库是后续业务逻辑进行升级或变更的最核心部分，只要数据记录的升级是顺畅，那改代码就比较容易。所以对字段的限定以及相应类型和长度，一般来说，要谨慎一些

比如说name字段它的长度，产品给出不超过32个字。像电影时长是一个分钟记录的话是一个很常见的整数值。
但是像没举和类地区，它反而是一个比较小的纸，用tiny int

2，对枚举和状态，我们会有一些保留字段，一般0不作为具体业务来使用。
比如枚举值里的零，一般代表是全部数据的意思。比如在列表页查询所有类型电影，这个时候就不能传1234567，传个0就可以。而在状态部分，一般我们认为0是删除态或者非法态，而1是正常态

3，然后再推剪辑里面的次数，一般情况下，不用考虑Bigint，大部分商业框架是达不到这个量级的，等到达到之后再去进行变更，也是没有任何问题。
但是早期设置这种字段，会对数据库的空间占用造成浪费