如何基于两个集合的反规范化实现套餐详情页数据展示？

一、套餐详情页的实现方案 #

针对详情页需要展示机构完整信息+旗下所有套餐的需求，有两种实用的实现方式：

方案1：双集合关联查询（推荐） #

从当前套餐的agency.businessId入手，分两步完成查询：

1. 用businessId到Agency集合查询该机构的完整信息（title、address、phone）；
2. 同样以businessId为查询条件，到Packs集合筛选出所有归属该机构的套餐。

移动端可以将这两个请求设置为并行请求，减少整体等待时间。如果套餐数量较多，给套餐列表加上分页逻辑（比如每页10条），避免一次性加载大量数据导致界面卡顿。

方案2：局部反规范化优化（可选） #

如果想进一步减少查询次数，可以在Agency集合中缓存旗下套餐的关键信息列表（比如套餐id、offer），这样查询机构详情时能直接拿到套餐列表的核心数据。但需要注意两点：

• 每次新增/修改/删除套餐时，必须同步更新对应Agency文档中的套餐缓存，否则会出现数据不一致；
• 只缓存必要字段，不要把套餐全量数据嵌套进去，避免Agency文档体积过大。

二、Agency集合添加大量引用的问题分析 #

在Agency中存储套餐id列表（大量引用）是否存在问题，取决于你的数据库类型和业务场景：

• 文档型数据库（如MongoDB）：单文档有默认大小限制（16MB），如果单个机构的套餐数量过千甚至过万，id列表会快速撑大文档，不仅影响查询性能，还可能触发文档大小限制。另外，每次操作套餐都要更新Agency的id列表，增加了维护成本和一致性风险。
• 关系型数据库：如果用外键关联，不存在文档大小问题，但批量查询套餐时需要用IN语句，当id数量过多（比如超过1000）时，部分数据库会出现性能下降，同样建议搭配分页查询。

如果你的业务中单个机构的套餐数量不会特别多（比如几百个以内），存储id列表是可行的；但如果存在大型机构套餐数量极多的情况，更推荐用方案1的关联查询+分页加载，避免潜在的性能和维护问题。

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