经典系统重塑（sql层）
内容
这个音乐门户网站是我一直在写的一个项目，因为周期较长，虽然功能都给予了大体实现，但是确实无论是sql层面还是业务层面都有很大缺陷。
先看最主要的music表，这music字段指的是音乐地址，名字需要改一下，还有musician_id和musician明显不符合三范式，删掉musician字段，与musician表进行连表查询，由于是发布专辑，专辑里有歌曲，所以歌曲相当于专辑的一个子，生命周期的create是相同的，所以把create_time字段转移到musician表中，其实可以把duration（歌曲时间），这种字段，新建一个music_data表然后移进去，但是现在关于歌曲信息的字段就一个，因为点赞数和评论数等信息是使用redis和count函数完成的，后期对点赞和评论系统进行优化的时候会进行涉及处理。这个create_time字段与这个time字段写重了，修改后music表结构为：
在mybatis-plus里的思想是一个表对应一个controller类，一个service接口，一个service实现类，一个mapper接口，一个Po实体类，但是由于是表分立的思想，所以他对连表的支持其实比较有限，需要嵌入sql语句，可读性和封装型都不如写mybatis的注解或xml。
对于表的修改还有就是对这个专辑表的专辑风格进行了修改，之前是varchar形式，现在修改成id。
当写这篇文章的时候，对于原系统的改造就已经彻底完成了，包括oss的文件转移到前端去实现。以及全部sql的改写
总结
总体来说，这次改造可以使系统结构更加清晰，可扩展性，抗压性，稳定性，合理性都有了质的突破，因为如果不进行重塑，该系统下的其他功能将会很乱，变成屎山。比如musician_name和musician_id同时存在，就只单单查询这一条sql业务简单了一点点，可能速度快了一点点点，但是面对音乐人注销，音乐人改名，这个业务就会变得及其复杂，难以维护