我有 3 种类型的实体：
- 科目
- 主题
- 任务
每个主题都有主题和任务。这些主题可以相互依赖。(当然，属于 sj1 主题的主题只能依赖于同样属于sj1主题的另一个主题。
在任务和主题之间有联系(也必须属于同一主题(，这象征着要解决某个任务，我们需要了解某些主题。
因此，一项任务可能需要更多主题。此外，更多任务可能需要一个主题。( N<--->M 连接。
存储的最佳解决方案是什么？
-
溶液
- 每种类型的实体有 3 个集合
- 在任务和主题中具有主题标识符属性的索引。
- 以及用于存储主题[N]<->[M]任务之间连接的边缘集合
-
溶液
- 有 1 个主题集合
- 对于每个主题，有 1 个主题和 1个任务集合。主题和任务/主题之间的连接可以基于集合名称的前缀。(即对于化学科目，我们有chemistry_tasks和chemistry_topics集合(
- 对于每个主题，有一个用于任务和主题之间连接的边缘集合，以及另一个用于主题之间连接的边缘集合(即chemistry_topics_tasks_connections和chemistry_topics_connections(
这样，如果我想在主题或主题的任务中进行搜索，则无需根据主题标识符索引预先过滤它们。我将立即获得包含我所有数据的所需集合。此外，我没有任务和主题中每个文档的索引开销。 另一方面，这将导致集合混乱。
旁注：最多有 50 个主题，但任务和主题的数量是无限的。
用你的话来说，"意识"是通过"图表"生成的，它不需要额外的索引来发挥最佳效果。 ArangoDB会自动创建特殊的"_key"和"_from/_to"索引，用于图形遍历。
但至于索引，关于所有搜索性能 - 索引是根据您要查找的数据添加的。 这实际上取决于您想要如何搜索：
- 一个集合具有多个实体类型或
- 按实体类型隔离的多个集合。
拥有大型集合不会受到惩罚，并且图形可以链接单个集合中的文档 - 它不需要将它们隔离。 此外，还可以有多个边缘集合和/或多个文档集合。 这些是挑战我们这些像我一样来自传统RDBMS的人的一些概念 - "无模式"或"多模型"数据库有点像规范化。
就个人而言，我选择基于数据源构建相当大的集合(我从外部源导入数据(。 每个集合都包含由objType属性标识的多个对象/数据架构的文档。这样做的好处是，您可以在单个字段(甚至是具有多个字段的索引，如title+objType(上搜索集合中的所有文档，非常快速地减少要迭代/遍历的文档集 -这通常是实现真正性能提升的地方。
所以。。。我想我推荐解决方案#3？