Open 9WiSHao opened 2 days ago
先前烂梗归类为固定几种分类,无法承担进一步细化归类的需求。 其次,“全部“里的数据与分类里的数据是分开的,造成数据源混乱,复制数等数据会重复存多次,热榜不好处理,会出现重复烂梗。
为适应后面的扩展,现期望改造后台数据储存格式,改成tag式存储。 具体为:每条烂梗只存一次,有一个固定id,每条烂梗可以对应多个tag 这样改造,首先统一数据源,每条烂梗只存一次,方便管理和后续扩展(比如加点赞功能,热榜不会出现重复数据) 并且可以细化分类,比如某烂梗现在属于喷选手,改造后除了喷选手之外,还能打上具体选手标签,比如niko,这样在喷选手标签下能找到这条烂梗,niko标签下也能找到这条烂梗。
数据库数据由每个分类一个表,改为所有烂梗都存在一个表中。每条烂梗能打多个tag怎么处理看怎么好做怎么来,自行决定。 注意扩展性,后面可能给烂梗加字段,比如点赞,添加时间之类的
需要一个接口获取所有tag,平替先前在前端写死的侧边栏分类。 具体是,接口返回一个数组,每个数组元素存储某个tag带有的所有信息,比如
[ { path: '/home', text: '首页', icon: home_icon }, { path: '/memes/AllBarrage', text: '全部烂梗', icon: all_icon, api: API.GET_ALL_MEME, category: 'allbarrage' }, { path: '/image', text: '时光相册', icon: image_icon }, { path: '/memes/penWJQ', text: '喷玩机器篇', icon: wjq_icon, api: API.GET_FK_WJQ_MEME, category: 'penWJQ' }, { path: '/memes/mygo', text: '木柜子篇', icon: mygo_icon, api: API.GET_MYGO_MEME, category: 'mygo' }, { path: '/memes/ZbjHuPen', text: '直播间互喷篇', icon: ZbjHuPen_icon, api: API.GET_FK_EACHOTHER_MEME, category: 'ZbjHuPen' }, { path: '/memes/penPlayer', text: '喷选手篇', icon: penPlayer_icon, api: API.GET_FK_PLAYER_MEME, category: 'penPlayer' }, { path: '/memes/p1', text: '+1', icon: p1_icon, api: API.GET_P1_MEME, category: 'p1' }, { path: '/memes/QMLW', text: '群魔乱舞篇', icon: QMLW_icon, api: API.GET_SHOWTIME_MEME, category: 'QMLW' }, { path: '/memes/QUQU', text: 'QUQU篇', icon: Z_icon, api: API.GET_QUQU_MEME, category: 'QUQU' }, ]
和现在根据分类获取其中烂梗的接口类似。 不过考虑到后面要支持联合查询,就是可以查多tag烂梗,比如查同时带有niko和喷选手tag的烂梗,个人认为采用固定接口,然后传参数可能比较合适。比如get后面跟query里面传好几个tag
前端应该不用变什么东西,或许烂梗统一到一个表里之后,每个对应固定id,+1接口就不用传分类了,简化成只传id
前端不用改动,后台注意这里需要改下搜索逻辑,因为数据存储格式变了
投稿先小改,只是把投稿分类换成投稿tag,用户投稿只能选一个tag,后面再考虑多个
审核的时候支持修改tag
数据迁移方案: 现状是每个烂梗在全部中和具体分类中都存了一份。统一到一个表里的话,取复制数高的那个或者加一块 一步一步来,先只是把固定分类换成tag,每个烂梗只对应现在所属分类的那一个tag即可。多tag的事情后面再考虑
后续工作: 多tag显示方案,需要考虑下。多tag 的话现在的单一侧边栏分类可能不太适合了
投稿 投稿的时候可以自己加新的tag,选多个tag,后续审核也要支持修改
后端投稿 管理部分完成
需求价值
现状
先前烂梗归类为固定几种分类,无法承担进一步细化归类的需求。 其次,“全部“里的数据与分类里的数据是分开的,造成数据源混乱,复制数等数据会重复存多次,热榜不好处理,会出现重复烂梗。
改造计划
为适应后面的扩展,现期望改造后台数据储存格式,改成tag式存储。 具体为:每条烂梗只存一次,有一个固定id,每条烂梗可以对应多个tag 这样改造,首先统一数据源,每条烂梗只存一次,方便管理和后续扩展(比如加点赞功能,热榜不会出现重复数据) 并且可以细化分类,比如某烂梗现在属于喷选手,改造后除了喷选手之外,还能打上具体选手标签,比如niko,这样在喷选手标签下能找到这条烂梗,niko标签下也能找到这条烂梗。
具体改造涉及部分
后台数据存储
数据库数据由每个分类一个表,改为所有烂梗都存在一个表中。每条烂梗能打多个tag怎么处理看怎么好做怎么来,自行决定。 注意扩展性,后面可能给烂梗加字段,比如点赞,添加时间之类的
接口部分
1. 获取所有tag接口
需要一个接口获取所有tag,平替先前在前端写死的侧边栏分类。 具体是,接口返回一个数组,每个数组元素存储某个tag带有的所有信息,比如
2. 根据tag获取烂梗接口
和现在根据分类获取其中烂梗的接口类似。 不过考虑到后面要支持联合查询,就是可以查多tag烂梗,比如查同时带有niko和喷选手tag的烂梗,个人认为采用固定接口,然后传参数可能比较合适。比如get后面跟query里面传好几个tag
3. 点赞数+1接口
前端应该不用变什么东西,或许烂梗统一到一个表里之后,每个对应固定id,+1接口就不用传分类了,简化成只传id
4. 搜索接口
前端不用改动,后台注意这里需要改下搜索逻辑,因为数据存储格式变了
5. 投稿接口
投稿先小改,只是把投稿分类换成投稿tag,用户投稿只能选一个tag,后面再考虑多个
6. 后台管理接口
审核的时候支持修改tag
涉及人员