When mapping to address mismatched dimensions between source and target is there a best practice to use a list property or metric? Seems to me the list property is the better choice since it’s the obvious place to look which prevents creating duplicates, which of course, can easily become out of sync. If list property is the way to go are there any downsides? Thoughts?
Solved
Best Practice Question: List Property or Metric?
+6- Master Trendsetter
Best answer by francois
Hi Jared,
Thanks for the relevant question - there is no proper best practice here, as it does not impact performance or overall architecture.
As of today, here are a few pros and cons:
Properties
- appear in groupings in the pivot panel
- are easier to type in in a formula (typing simply
Dimension.Property) - can be chained (
Dimension.'Grouping 1'.'Grouping 2'.'Grouping 3')
Metrics
- do not “pollute” the pivot panel
- are easier to manage if you have a lot of them (e.g. more than 30-50 in your dimension, depending on your tolerance) and can be stored in folders / subfolders
- are very easy to migrate should you want to update the structure, if you decide your grouping changes over time.
This last one means that if you use a metric to store the Employee’s Country and want that to be dependent on time, all of the metrics that use it will auto-update after changing the structure of your mapping metric.
While your app grows, it’s normal to go from the easiness of the property to the versatility of the metric at some point, but Pigment makes it easy to migrate from one to the other.
Hope this helps!
Pigment + Retail
+13- Employee
- Answer
Hi Jared,
Thanks for the relevant question - there is no proper best practice here, as it does not impact performance or overall architecture.
As of today, here are a few pros and cons:
Properties
- appear in groupings in the pivot panel
- are easier to type in in a formula (typing simply
Dimension.Property) - can be chained (
Dimension.'Grouping 1'.'Grouping 2'.'Grouping 3')
Metrics
- do not “pollute” the pivot panel
- are easier to manage if you have a lot of them (e.g. more than 30-50 in your dimension, depending on your tolerance) and can be stored in folders / subfolders
- are very easy to migrate should you want to update the structure, if you decide your grouping changes over time.
This last one means that if you use a metric to store the Employee’s Country and want that to be dependent on time, all of the metrics that use it will auto-update after changing the structure of your mapping metric.
While your app grows, it’s normal to go from the easiness of the property to the versatility of the metric at some point, but Pigment makes it easy to migrate from one to the other.
Hope this helps!
François (Pigment)
+6- Master Trendsetter
What a terrific answer
+13- Employee
I hope not! On larger app creation, I see it can be common to create multiple flows that are quite similar - but with a good folder structure, this should not happen too much.
I guess this is not different to any other calculation process where you always run the risk of computing things twice, especially when your app goes above a size where you can remember what all blocks do - but this is not unique to metrics either, this also applies to properties too. If a dimension has more than, say, 100 properties, you also run the risk of forgetting what each does.
As for performance, Pigment tries to prioritise the calculation of the most “active” blocks, e.g. those that are displayed, or are part of a chain of calculation that will be displayed somewhere. There are active developments to make sure that dead ends (e.g. blocks that are calculated but not used in important dashboards) are less likely to be computed first, to make Pigment run the most important blocks first, always.
It’s better to not compute them in the first place, but if you end up with duplicates it’s not the end of the world.
François (Pigment)
+6- Master Trendsetter
I crisply salute you
Pigment + Retail
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.