基于SQL设计Reddit评论API：数据存储与接口实现问询

我们正在为Reddit的新后端构建支持其应用的评论模型，已设计出如下评论结构（右侧数字为Like count）：

- Comment uuid 1: (Root level comment)                   89
|-- Reply uuid 2 (First level reply comment).            150
    |-- Reply uuid 7 (Second level reply comment)        92
         |-- Reply uuid 8 (Third level reply comment)    40
|-- Reply uuid 3 (First reply comment)                   112
|-- Reply uuid 4 (First reply comment).                  1
    |-- Reply uuid 9 (Second level reply comment).       0
         |-- Reply uuid 10 (Third level reply comment).  3
|-- Reply uuid 5 (First reply comment)                   5
|-- Reply uuid 6 (First reply comment)                   10
    |-- Reply uuid 11 (Second level reply comment).      78
         |-- Reply uuid 12 (Third level reply comment)   200

目标：编写一个API，针对指定Root level comment获取按Like count排序的前5条评论；若评论为Second或Third level reply comment，则获取完整线程，且API每次返回不超过5条评论。
示例：API第一次调用返回评论2、3、6、11和12；第二次调用返回评论7、8和5。

请解答以下技术问题：

1. 如何在SQL中存储这些数据？已知评论包含ID、评论内容、Like count、时间戳及Parent Comment ID。
2. 该API的设计方案是怎样的？是否需要使用单个复杂SQL查询？

问题1：SQL存储方案 #

用单张comments表就能搞定所有评论的存储，表结构如下：

CREATE TABLE comments (
    id UUID PRIMARY KEY,
    content TEXT NOT NULL,
    like_count INT NOT NULL DEFAULT 0,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    parent_comment_id UUID REFERENCES comments(id)
);

• id：评论的唯一标识，对应示例中的UUID
• parent_comment_id：父评论ID，根评论的该字段设为NULL（符合SQL关联规范），子评论通过该字段关联到父评论，清晰表达层级关系
• 其他字段按需求存储即可，后续通过递归查询就能快速获取任意评论的完整线程。

问题2：API设计方案 #

核心逻辑 #

API需要兼顾排序优先级、线程完整性和分页限制三个核心要求：

1. 排序规则：所有评论按like_count降序排序，但遇到二级/三级评论时，必须拉取其所在的完整线程（从直接父级到该评论的全路径）
2. 分页控制：每次返回结果不超过5条，需要记录游标（比如最后一条返回评论的like_count和id）作为下次调用的起始位置，避免重复返回
3. 线程处理：遍历排序后的评论列表时，若选中的是二级/三级评论，需先将其完整线程的所有评论加入返回集合，同时跳过列表中属于该线程的其他评论，避免重复

具体实现步骤 #

1. 基础数据查询：用SQL查询指定根评论下的所有层级评论，按like_count降序排序，同时通过递归CTE生成每条评论的完整路径（比如path = '1->6->11->12'），方便后续识别线程关系
2. 应用层处理线程与分页：
   • 遍历排序后的评论列表，维护一个返回集合和已处理的线程ID集合
   • 若当前评论是一级评论，直接加入返回集合；若为二级/三级评论，先检查其所在线程是否已处理，未处理则将整个线程的所有评论加入返回集合
   • 当返回集合的数量达到5条时停止，记录当前游标（最后一条评论的like_count和id）
3. 返回结果：将整理好的评论集合返回给客户端，同时携带游标信息供分页调用

是否使用单个复杂SQL？ #

不建议用单个复杂SQL实现，原因如下：

• 递归查询+排序+线程完整性+分页的组合SQL会极度复杂，维护成本极高，且大数据量下性能会急剧下降
• 拆分SQL和应用层逻辑更合理：SQL负责基础的排序和路径生成，应用层负责线程完整性校验和分页控制，逻辑更清晰，后续规则调整也更灵活

内容的提问来源于stack exchange，提问作者technophile