Hey, I am modeling various insurance products across different domains and so far modeling these as graphs were way easier than doing so as an ER model.

However, for the travel domain, I got over 550 different prices in a long Excel sheet that follow a certain standard format:

The goal is to find for a given travel of a given length, to a given destination region the plan with the lowest price.

Conventionally, this is just a look-up from a data table and then just sort the results by price.

In a graph, well, here we go.

Common sense, to me, would be to align the look-up graph with the question one would ask a customer, like:

- Domestic / International
- Region: Asia / US / Etc
- Duration i.e. number of total days
- Number of travelers i.e. alone, couple, group
- Any extras?

And from there, traversing the graph and returning all the nodes, sorted by rate. From the >550 combinations, I may reduce it to say 5 - 10 at most.

And here is the big question:

Should I link each result node to the corresponding insurance plan *or* is it better just placing the plan id as property and just look it up on demand?

Due to the complex pricing structure, adding a relation to each matching plan, I get easily several dozens of relations to each plan but afaik, there is a real cost to nodes with a large number of relations.

So what's the best way of modeling the case w.r.t. to sustaining performance in an online system?