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?