I’m in the midst of my first app and am finding myself adding more and more calculated columns in my users table. At what point should I start being concerned? Right now, I’m at around:
50 columns total
15 actual data columns from Google Sheets
5 relations
20 lookups
The rest a combo of templates, if-then-else, etc.
A thing that seems weird is all of the lookups. I’m basically bringing in all of the columns from the related table. This seems inefficient as far as process goes, and I feel like there should be a more direct way to access this info than to add a lot of lookup columns. Then again, this also seems like the more manual version of what’s happening in a SQL join.
As @ThinhDinh mentioned, 50 computed columns is generally nothing to worry about. It just depends on what they are doing and how many rows they are operating on. But things like relations/lookups/templates should be no problem at all.
AWESOME!!! I figured there’s a reason for a search box whne I’m selecting a column.
This is an agenda app for a two-day event. Each user has a selected lunch group each day, and a selected activity each day. Lunch groups and activities have 5ish columns of info, which are what I’m pulling into the user’s row with lookups. This is letting me do things like generate custom messaging and blocks of info using a lot of template and if-then-else columns. So for example, a sentence that says “You’ve chosen X as your Wednesday activity and Y as your Thursday activity.”
Not sure if it can work better for you, but I would advise:
Creating a JSON object on the original table that store the info, including all the info you need for the lookup.
Use only one lookup on the destination table to bring the JSON over.
At that point, there are 2 choices for you, one is to deconstruct the JSON using the query JSON column (won’t reduce the numbers of columns if you want to deconstruct them all), or use JavaScript and dynamically access the variables inside the JSON to construct the message using the JavaScript column directly.