如题,我指的典型的比如 Pixiv 的 tag 系统,一个 tag 可对应任意多 item,一个 item 可对应任意多 tag,典型的一对多关系。
在考虑设计的问题,简单想一下有几种存储方案,假设要给文章加标签的话 1、简单的两张表,一张存文章,一张存 tag,tag 有 tagid 和对应的文章 id,查询时连表 2、三张表,一张存文章,一张存 tag,一张存对应关系 3、文章表里新建一项 varchar (或 text ),以字符串形式储存所有 tagid,以特殊符号分割,查询时由前端(引擎)处理 tagid,再向 tag 表发出 query
有没有有经验的带佬分享一下可维护性和性能两方面看,哪种设计最好。
1
nvkou 2020-03-18 00:44:51 +08:00 via Android 1
这是多对多吧。
要看你业务,有没有 tag 查文章,文章查 tag 这样的需求。 要灵活还是选 2。定义好外键和索引就是 |
2
black11black OP @nvkou 手抖
|
3
min 2020-03-18 08:34:46 +08:00
小规模数据基于数据库问题不大,否则需要专门的方案,建议搜一下 stackoverflow 做法
|
4
www15119258 2020-03-18 16:05:01 +08:00
我的经验是使用三张表,在存储关系表的同时,索引数据到 es,es 数据使用你的第三种方式存储,这样,根据 tag 检索文章 id 很快,然后再根据文章 id 去关系库查数据。
|
5
black11black OP @www15119258 没太听懂,两种业务一种是根据文章查 tag,一种是根据 tag 查文章,大佬说的根据 tag 搜 id 再查关系数据库是哪种业务
|
6
www15119258 2020-03-19 12:26:18 +08:00
@black11black 根据文章查 tag 一般没问题,一般都是根据 tag 查文章的时候有性能问题,如果是纯关系数据库很难解决性能问题,所以要借助 es 索引解决。es 索引的时候可以将 tagid 用逗号分隔,可以很快的根据一个 tagid,或者多个 tagid 查询到关联的文章 id,一般文章列表都是分页的,有这些文章 id 了,再去关系数据库里面取文章就行了。
|