ArangoDB多类型记录按日期排序查询及建模方案咨询

针对你的需求，逐一分析四个方案的优劣，并给出最优建议：

方案1：单集合records存储所有类型 #

• 优点：混合查询逻辑最简单，直接执行以下AQL即可高效获取结果：

  FOR r IN records
  FILTER r.createdByUserId == @userId
  SORT r.createdAt DESC
  LIMIT 20
  RETURN r
  

  只需在records集合上创建(createdByUserId, createdAt DESC)的复合索引，就能确保查询性能拉满。
• 缺点：不同类型记录的字段差异会导致文档结构不统一，比如视频的duration、图片的width只会出现在对应类型的文档中。但ArangoDB作为文档型数据库，天生支持灵活的文档结构，只要通过type字段（如type: "video"/image/story）明确区分类型，并不会带来维护上的问题。如果你的单类型记录操作（如批量统计视频时长）占比不高，这个方案的性价比极高。

方案2：UNION合并多集合查询 #

• 问题：性能瓶颈明显。即使每个集合都创建了(createdByUserId, createdAt DESC)索引，UNION需要分别从每个集合取出用户的所有记录，再合并后排序取前20。当用户的记录量较大时，合并排序的开销会急剧上升，且无法利用全局索引优化整个查询流程，完全不适合生产环境的高性能需求。

方案3：父表+子表结构 #

• 优点：完美兼顾混合查询性能与单类型记录的逻辑独立性：
  1. 主集合Records存储所有类型的公共字段：_key, createdByUserId, title, createdAt, type，创建(createdByUserId, createdAt DESC)复合索引，混合查询时只需操作主集合，直接取前20条最新记录，性能和方案1一致。
  2. 子集合Videos/Images/Stories存储各类型的特有字段，通过recordKey关联主集合的_key。如果需要展示完整的记录详情，只需在获取主集合的20条记录后，通过recordKey批量关联对应的子集合数据，由于仅关联20条数据，开销可以忽略。
  3. 单类型操作（如查询用户所有视频）也能高效执行：

     FOR v IN Videos
     FOR r IN Records
     FILTER r._key == v.recordKey AND r.createdByUserId == @userId
     SORT r.createdAt DESC
     RETURN MERGE(r, v)
     

• 缺点：需要维护主、子两个层级的集合，写入时要先写主集合，再写对应子集合，增加了一点写入复杂度，但对于大多数应用来说，这点复杂度完全可以接受。

方案4：边集合关联 #

• 问题：边集合更适合表示多对多或复杂的关系（如用户关注记录），而将creatorId直接作为记录属性的方式，比通过边关联用户的查询效率更高——直接通过属性索引就能定位用户的记录，无需额外遍历边集合，因此这个方案完全不符合你的需求。

最终建议 #

优先选择方案3（父表+子表结构），它既保证了混合查询的极致性能，又保留了单类型记录的逻辑独立性，是最平衡的设计。如果你的应用中单类型记录的操作极少，且可以接受文档结构的灵活性，**方案1（单集合）**也是一个极简高效的选择。

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