Feeder performance - Which is better to feed from?

[Bakkone]

Hi,

Lets say we have the following rules:

= N: [Headcount] * [A] ;

[D] = N: * [C] ;

When feeding [D]. Would you feed from or from [Headcount] and why? Is there any effect on performance in feeding from a value not part of the rule? Guess Im looking for some best practice.

Personally I put [Headcount] => , [D] ;

This emphasizes that Headcount is really the trigger of the calculation and makes for fewer lines.

[gtonkin]

If Headcount is the logical dependent variable, then it would make sense to use it. Obviously is 'A' is zero both 'B' and 'D' would be fed but that depends on your model and the business rules you are applying.
If you fed 'D' from 'B', it would have a performance impact as for any 'Headcount' or 'A' values, both would be fed into 'D' - longer time to process, should be same memory usage as only one cell ends up being fed. Also remember that 'D' is now fed whether 'C' has a value or not. Depending on the model, 'C' may be better to feed 'D'.

In terms of feeding from a value not part of the calculation (rule), I have some models where a Standard is derived from a cube for each cost centre. I use an active flag on the cost centre to feed a rollup of all the Standards. So yes, you could use an independent value that may always be populated. The catch however is if you use it to feed a calculation that like your example has a dependent variable - rather use that than a "proxy" otherwise you could end up with lots of cells containing zeroes and being fed. And should those cells feed onwards, you will overfeed even further.

[jim wood]

The way always thought of it, you feed from the driver of the calculation, so for example if you only want values to appear when you have a headcount then you feed with headcount. If however either value could drive the calculation then you need to feed with both. The obvious example I always give is:

Code: Select all

['Sales'] = ['Units Sold'] * ['Price']

You'd only want to see a sales value when you've actually sold something so feeding with price wouldn't make much sense. If you try to work the same logic you'll get there. Sometimes the drivers aren't so obvious and as I mentioned above there could be multiple.

[whitej_d]

I think there's an argument for readability too. If you're trying to debug rules and feeders, the natural place to look for the feeder is in the components of the corresponding rule. If you feed from components that are not part of the rule, It gets hard to manage pretty quickly, particularly if you feed from another cube. What tends to end up happening is that when there's a bug and a feeder is to blame, nobody can find the feeder based on the rule and therefore they end up writing a new feeder. I think if performance isn't an issue, then there is a readability benefit to having the feeder logic mirror the rule logic as much as possible. There's definitely arguments for both approaches though.

[Bakkone]

Thanks for the replies.

I like the principal of the feeding from the original driver of the calculation. In this particular case it is the Headcount. The other variables would be different percentages and stuff... I didn't want to write everything out to make it a bit more clear.

The readability thing shouldn't be underestimated. I've found myself doing a lot of extra work because I missed how things are connected. I've been trying to work on this. Nowadays I try to add numbered sections and subsections of the rules, and then using the same numbering for the feeders. This together with extensive comments help out a lot. That means that I can make messy rules and feeders that are just the best from a performance perspective.

Hope to see more discussions and comments regarding this on this forum. Hopefully the new performance monitoring tools will help us in the future.