The question is related to financial products, interest rates and two properties that determine which interest a certain product has. But I think fruits and baskets are easier to visualize for this.
First, we have fruit. Fruit can have a specific size (Small, medium, Large) and colour (Red, Green, Blue). These will be two different enumerations. Baskets will contain all kind of fruits, but no two are identical in colour or shape. But every possible combination will be in the basket. Since we have three sizes and three colours, we will end up with 9 pieces of fruits in every basket. If we had 4 colours, we would end up with 12 pieces.
We store the basket information per basket. Every basket has a Dictionary<{Size, Color}, Fruit> which defines all the pieces of fruit in the basket. However, this dictionary might not be completely full, in which case all other combinations are apples. The dictionary only contains fruits of a different kind. (Although they too can contain apples.) Next to apples, we also have pears and banana's. Yeah, they could be red but I would wonder what kind of paint was used to make them red. Remember, this is just to visualize the problem. :-)
Anyway, I now have a list of baskets with per basket a list of fruits. Apples by default, Pears or bananas if they're in the Dictionary. But I need to look at the information from a different angle.
I need to convert this structure to a list of fruits and per fruit the baskets where they can be found, plus the sizes and colours of the specific fruit. Thus, bananas are in basket 1 ({small, yellow}, {small, red}, {medium, red}), basket 3 (...), basket 4, 8 and 10. Same with pears, but I can't have a yellow pear in basket 1, since that one is already defined for a banana.
I have a big advantage: none of these structures are clearly defined yet! However, I need the Basket view as a way to provide the information to the conversion process. And I need the Fruit view for further calculations since I need to do additional math based upon just the fruit itself, not their size or colour or the basket where they're from...
So, any good suggestions for the structure before and after transformation and how to do the transformation itself, using Linq in C#?
In real, the baskets are products. The size and colour are smaller variances on the products. The fruit are interest rates and I only need this rate to do the math. By grouping the product by their interest rate, I can reduce the number of calculations to just a few. We're dealing with 1600+ products with per product about (10x10) 100 different variants, thus a total of 160.000 interest rates. The rates themselves are generally between 3 and 7.5% and rounded to 1/20th of a percent. Thus, about 90 different rates resulting in 90 calculations instead of 160.000 calculations...
And I need to convince management to take this step because they fear it's lots of work, becomes unreadable or will be hard to maintain.
Based on the interest rate, you can calculate how much a person can loan based upon how much he's willing to spend per month on a product with certain conditions. This optimization will allow me to make much faster comparisons between different products. Too bad I'm the first in the company who noticed this interesting optimization! :-)