让我们说我有3种不同类型的节点，计划，大创意和想法。
现在每个计划可以包含0 + Big-Ideas和0+ Ideas，以及这些关系的权重（投票）。思想也可以创造出大创意。
例如，给定计划A.
A -[:HAS_BIG_IDEA {Weight: 30}] -> B (Big-Idea)
A -[:HAS_IDEA {Weight: 10}] -> C (Idea)
A -[:HAS_BIG_IDEA {Weight: 1}] -> D (Big-Idea) -[:IS_MADE_OF {PlanID, Date, Weight}] -> E (Idea)
每日更改计划，每天也会投票。最初，我决定为每种类型的计划设置一个节点，并且每天添加新关系，其中包含日期和重量的属性。问题在于，随着想法和大创意的数量达到数百万，关系的数量开始膨胀和过滤基于日期和权重的计划变得慢得多。
例如，查询列出2017年7月7日使用的所有观点的投票＆gt; 100执行需要更长的时间。为了减少起点的数量，我将Date属性转移到了Plan节点，并为每个类型和日期创建了新的Plan节点。由于这会降低查询的起点，因此会加快查询速度。缺点是创建更多节点。
所以我想我的问题与我的第二种方法是否是一种好的做法有关。我已经读到使用关系上的遗留索引提示重新设计图表所以我不太热衷于在关系的日期/权重上添加索引。