Which is better for Parent/Child maintenance/performance - Virtual Columns or managed normal column?

[WillowMobileSys]

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:

1. I can implement the display lists as Virtual Columns to easily stay updated with any changes made to the Child lists.

2. 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.

[1minManager]

I’m struggling to fully understand your use case here. But I have 2 suggestions to make the VC as fast as possible. Firstly always point it at the [Related XXX] column as appsheet always has to calculate this. Also use an if statement that give the formula a quick way to end e.g.

IFS(
[Foo]=0,"",
…
)

[WillowMobileSys]

1minManager:

I’m struggling to fully understand your use case here.

Thanks for the reply! Here is an Image to clarify use case. I was trying to be somewhat generic as the problem arises for any Parent/Child where the Parent is trying to display data based on the children - such as Summary calculations.

---

Below is the Detail view of my Parent Item. At the bottom, the “Assigned Option Details” (table not included in the image) is the complete list of Child rows attached to this Parent.

At the top are those same children rows but grouped by the categories - “Color Group Options”, “Gauge Options”, “Nose Options”, etc. This allows easier viewing of the options for this item - I think.

From this Detail view, if I tap “View” under the “Assigned Option Details” to see all options and then select one of them, I can Delete it and it will be removed from the Child list. BUT, the option Categories will not update - unless I make them VC’s or add additional functionality for a “custom” Delete that re-calc’s the category lists.

I hope this helps.

[1minManager]

So if you changed them to virtual columns then note that VCs in a detail view only update during a sync. Whereas exactly the same VC in a form view updates on any change. Not really a way to get around that.

First thought, if you need to show exactly like this, change these 5 VCs to standand columns. Then create/edit the delete button so that a formula updates these standard columns. Kinda like you mentioned

[1minManager]

Only other way would be to work on the inline view to display the subtable in a different way