Let's say that I have 3 different types of nodes, Plans, Big-Ideas and Ideas.
Now each Plan can consist of 0+ Big-Ideas and 0+ Ideas, along with weights (votes) for these relationships. Big-Ideas can also be created by Ideas.
For example, given plan 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)
Plans are changed daily, with votes being given daily as well. Initially I decided to have 1 node for each type of Plan and have new relationships added daily with the properties for Date and Weight. The problem is that as the number of ideas and big-ideas number in the millions, the number of relationships starts ballooning and filtering Plans based on Dates and Weights becomes much slower.
As an example, the query to list all ideas used on 7th July 2017 which had votes > 100 takes much longer to execute. In order to reduce the number of starting points, I shifted the Date property to the Plan nodes and create new Plan nodes for each type and day. As this reduces the starting point of the query, it speeds it up. The downside is creating more nodes.
So I guess my question is more design related as to whether my second approach is something which is good practice. I've read that using legacy indexing on relationships hints towards redesigning the graph so I wasn't too keen on adding indexes on dates / weights for relationships.