请教一下，类似于微博评论的功能怎么做的，或者说表该怎么设计

添加冗余字段来处理呗

可以使用 MySQL Referential Actions dev.mysql.com/doc/refman/8.0/en/cr...

表结构和你一样，我这边做法是按条件全部取出来，然后在函数里面进行递归整理好层级顺序

分类表：id，parent_id（分类上级 ID），path（如：1,3,4,7 4或7是上级分类）

文章表：id，parent_id（文章上级 ID）

评论表：id，article_id（文章 ID）

评论详情表：id，评论表ID

分批删除

1. 查询所有子分类 ID
2. 根据分类id 分批次查询文章
3. 根据获取2部的文章ID 查询评论及评论内容，并删除
4. 返回删除文章，获取2部的文章ID对应文章
5. 当评论，文章删除干净后， 删除对应分类

当然我建议加个 回收站功能， deleted_at, 也可以定时清理指定时间之前的内容，如1月之前的

删除文章 就把文章的下级删除就行 评论不用管（没有文章了，也就没有查看对应评论的入口了）

业务要求高 就用观察者 不高就用外键不就够了

文章表

评论表：

删除 id = 1 的1 级文章及下级所有文章
Article::where('id', 1)->delete();
Article::where('id', 'like', '1%')->delete();
这样和 id = 1 的所有相关文章就删除了
删除这些文章下的评论就用观察者就行了

有没有可能加一个 level 的字段来表示是第几楼，再加一个pid 表示父级。全都查出来重新组装就好了。

我的想法是代码逻辑里面删除当前层级，更多层级的工作交给任务队列，这样在保障了性能的情况下，用户体验也不会有太多损失

添加一个 descendants json 字段, 存储所有子孙的id

该冗余冗余， 不能总撞库， 一个请求能解决就一个。
楼上挺多说法， 直接一个 json 冗余出来我比较支持。
不过要实现对应的观察者， 在文章/评论出现更改时， 同步这个 json，或者同步到缓存里。

其他说法在 dba 和产品理解的角度更科学， 但是会显著增加代码成本，后期维护的理解成本， 没啥必要。 我们追求的是把产品先突突出来， 不是做科学家。

关联模型，删除时laravel可以触发一个 Eloquent ORM 提供的 deleting 事件，可以删除关联的所有数据