请教大佬，我这 SQL 写的有没有问题？

[cl903254852]

article(文章表)：

article_content(文章内容表)：

article_tag(标签表)：

article_type(分类表)：

---

其中 article(文章表)、article_content(文章内容表) 是一对一关系

article(文章表)、article_tag(标签表) 是多对多关系，关系表 tag_article 如下：

article(文章表)、article_type(分类表) 也是多对多关系，关系表 type_article 如下：

---

需求

查询所有文章，包含以下数据：

• id：文章 id
• title：文章标题
• tag_id：当前文章下的所有标签 id
• tag_name：当前文章下的所有标签名
• type_id：当前文章的分类 id
• type_name：当前文章的分类名称

然后我自己写的 SQL 是这样的：

SELECT 
a.id, 
a.title,
GROUP_CONCAT( distinct t.tag_id),
GROUP_CONCAT( distinct type.type_id),
GROUP_CONCAT( distinct a_tag.tag_name),
GROUP_CONCAT( distinct a_type.type_name)
FROM article a  
JOIN tag_article t ON a.id=t.article_id
JOIN type_article type ON a.id = type.article_id 
JOIN article_tag a_tag ON a_tag.id=t.tag_id
JOIN article_type a_type ON a_type.id=type.type_id
GROUP BY a.id;

结果：

结果也能出来，但我心里总有点不踏实。

各位大佬，我这 SQL 写的有没有问题？或者不严谨的地方？

ps:鄙人也是刚入门 Mysql，轻喷☹️

[wangyzj]

表结构不大好

[leewea]

头像不错

[xwbz2018]

标签和分类可以冗余到文章表里

[newtype0092]

tag name 和 type name 这种最好放在 redis 里，查出来 id 之后去 redis 里拿出来，现在这样 join 出来很多多余数据。
你这种不用 left join 没有问题么？

[cl903254852]

@xwbz2018 我特意问过同事，他们也喜欢这样冗余，用一个字段来存关系。但我总觉得这样不好，我还是觉得把关系抽离成中间表才是正规做法。

[cl903254852]

@newtype0092 对的！大佬！！！ 这样确实会 join 出来很多多余数据(left join 也是)，是我使用姿势错了？。 请问怎么解决呢

[cl903254852]

@leewea 😹

[cl903254852]

@wangyzj 虚心请教，应该改成什么样才算好

[gIrl1990]

article(文章表)、article_tag(标签表) 是多对多关系
article(文章表)、article_type(分类表) 也是多对多关系

有木有感觉其中一个是多余的？ 都是多对多 那“标签”和“分类”有啥子区别？

[xwbz2018]

@cl903254852 #5 标签和类型会不会修改？标签和类型多不多？我 join 用的不好，你看看没有分类、标签的数据能不能查出来

[linxiaojialin]

为啥执着于一条 SQL 查出所有数据呢？可以分成 4 次查出来的。

另外，如果你是 PHP && Laravel 的话，设置好 Model Relation，可以用 with 解决 N+1 的问题，例如：
```
$articles = Article::query()->with(['content', 'tags', 'types'])->paginate(10);
```

[cl903254852]

@linxiaojialin 我用的 Nodejs。 多次查会影响性能 我尽量一次查出来

[cl903254852]

@gIrl1990 分类范围比标签大。 请不要关心业务问题

[ebony0319]

我用 Postgresql 给你重构一下：
```sql
SELECT
a.id,
a.title,
string_agg((select distinct a_tag.tag_name from article_tag a_tag inner join
ag_article t on a.id=t.article_id inner join
type_article type ON a.id = type.article_id inner join
article_type a_type ON a_type.id=type.type_id),',')
FROM article a
```

[gIrl1990]

@cl903254852 https://v2ex.com/t/609544?p=1#r_8031352
这个“范围” 区别体现在哪？按你的“标签”“分类”设计 A 文章分在标签 b 和 A 文章分在分类 b 有啥子区别？

[gz911122]

@cl903254852 冗余下去好一些..
单独出来没太大必要啊...

不过这种帖子文字类的用 mongo 比较舒服,postgre 也行 mysql 完全是给自己制造复杂度...

[wongyusing]

你这样的表结构感觉很奇怪啊
文章表、文章内容表可以合并在一起。
没必要设置成一对一。
而文章类型和文章标签为什么都用多对多啊？？

正常来说，文章和文章类型属于外键关联。
文章和文章标签是多对多。

而且你的分类哪里不应该用 type，在某些编程语言中属于是关键字。
应该用 category

[inhzus]

合理的逻辑应该是 类型和文章一对多，文章和标签多对多，

[taogen]

主键关联没什么大问题，就是业务关联看起来有点多。关联太多性能会比放在一张表差，但这些减少了数据的冗余、不一致性。

建议用 left join。join 等于 inner join 取的是交集。

[wangyzj]

文章分类 article_type 单独一个表
文章标题 article 和文章内容 article_content 一张表，增加 article_type_id 字段外键对应 article_type 的 type_id, 再增加一个 tag text 字段，把所有标签排重放里面做成数组，用 Sequelize 定义 model 的时候加一个 get 方法自定义 JSON.loads 这个字段自动转换成数组取出