思考题：如下场景如何设计mongo collection
这篇探讨的是一个实际场景下的 MongoDB 集合设计问题：如何记录用户每次登录的业务标识、IP 及时间，并高效查询特定用户在特定业务下的某个 IP 是否已存在。 作者给出了两种思路并进行了对比。方案一采用扁平结构，为每次登录记录一条独立文档，结构清晰，查询时通过 `findOne` 直接定位。方案二则将同一用户同一业务下的所有登录记录聚合到一个文档中，将 IP 和时间存储为子文档数组，这在查询特定 IP 时语法略显复杂。 文章的核心矛盾点在于如何权衡查询的便捷性与应对新需求的灵活性。当需求变更为“每个用户同一业务只保留最新5条记录”时，方案一需要额外的计数与删除操作，而方案二则更利于在应用层（如 PHP）对数组进行裁剪后整体更新。作者最终选择了后者，并通过客户端脚本管理数组元素，再使用 `upsert` 操作同步回数据库。这反映了在 NoSQL 设计中，有时需要结合应用逻辑来弥补数据库层功能的不足。