I have an inner struggle I’m hoping to get help with.
My use case is I have a Parent Item that is assigned a list of Child Options. The Child Option will not change frequently, if at all. I want to show these list of options on the Parent views broken out by category. If I Add or Delete to the Child Options list, I want the Parent Category lists to reflect this change.
If I Edit the Parent and Add a new option all is well.
The problems
-
When Editing the Parent and drilling into the Child list, we are not afforded the opportunity to Delete a Child.
-
We can Delete from the Detail Views but then the Parent formulas are not executed that would keep the display lists updated.
I can solve this is two ways:
-
I can implement the display lists as Virtual Columns to easily stay updated with any changes made to the Child lists.
-
I can store the Category Display lists in normal columns and implement constructs to keep the columns updated, no matter where the changes are made, with custom actions, workflows, etc.
The Struggle
Virtual Columns, as many of us know, execute on each Sync. Because the Child Option list doesn’t change very often, these Virtual Columns will recompute the same lists over and over again. This seems an unnecessary hit to the app performance.
On the other hand, implementing a series of actions, workflows, etc to keep the columns updated bloats the app with extra components and complicates the app maintenance. But is much more performant in retrieval and display in the app from an end users perspective
Bottom line is that it is CRITICAL to keep our apps as performant/speedy as possible.
So…I am wondering if the extra time, effort and complexity with implementing the manual/custom maintenance of the normal columns is worth the performance savings of avoiding Virtual Columns?
And, yes, I know there are many factors that affect the outcome. I am looking for an opinion from a general perspective.
