动态数据展示：SQL逻辑与前端映射方案选型咨询

针对当前固定32隔间场景的适配性分析 #

SQL逻辑方案 #

这个方案的核心是后端通过SQL生成1-32的所有隔间编号，再左关联用户的药品记录，直接返回包含空隔间标记的完整数据。

• 优势：前端拿到数据后可直接渲染，无需额外处理逻辑，代码更简洁；如果后续有其他客户端（如APP、小程序）调用该API，不用重复开发补全空隔间的逻辑，保证多端数据格式一致；后端统一控制数据输出，减少前端出错概率。
• 不足：原SQL里手动写32个UNION略显繁琐，不过可以用MySQL 8.0支持的递归CTE优化，生成1-32的编号列表，写法更简洁：

WITH RECURSIVE compartments AS (
    SELECT 1 AS compartmentNo
    UNION ALL
    SELECT compartmentNo + 1 FROM compartments WHERE compartmentNo < 32
)
SELECT compartments.compartmentNo, 
       IFNULL(schedules.occupied, FALSE) AS occupied, 
       IFNULL(schedules.schedules, '[]') AS schedules
FROM compartments
LEFT JOIN (
    SELECT compartment, TRUE AS occupied, JSON_ARRAYAGG(JSON_OBJECT(
        'medicineName', medicineName,
        'quantity', quantity,
        'day', JSON_PARSE(day),
        'time', time,
        'dose', dose,
        'start_date', start_date,
        'end_date', end_date
    )) AS schedules
    FROM Tablets
    WHERE userId = ?
    GROUP BY compartment
) AS schedules ON compartments.compartmentNo = schedules.compartment
ORDER BY compartments.compartmentNo;

前端映射方案 #

该方案后端只返回有药品的记录，前端负责补全1-32的空隔间并排序。

• 优势：后端API逻辑极简，开发和维护成本低；返回的数据量更小（当用户仅占用少数隔间时）。
• 不足：前端需要额外编写补全、排序逻辑，代码量增加；如果有多个客户端调用，每个都要重复实现这段逻辑，容易出现不一致；前端处理过程中可能出现排序错误、空判断遗漏等问题。

当前场景推荐：优先选择SQL逻辑方案
因为隔间数量固定为1-32，且SQL可通过CTE优化写法，后端处理后的数据直接可用，能避免前端重复逻辑，更适合长期维护和多端扩展。

通用场景下的推荐原则 #

1. 优先后端处理的场景：

   • 需要返回固定范围的全量数据（含空项），且存在多个客户端调用API时；
   • 前端资源紧张，希望减少前端逻辑复杂度时；
   • 数据格式要求统一，避免多端实现差异时。

2. 优先前端处理的场景：

   • 数据范围不固定（比如未来隔间数量可能变化），前端调整范围比后端改SQL更灵活时；
   • 仅单一前端客户端调用API，且前端处理逻辑简单易维护时；
   • 数据量极大（比如上万条空项），后端生成全量数据性能开销过大时。

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