Ok, now that it all works beautifully, I wonder if we could go one step further…
Can we create a virtual Index? so instead of creating 100 rows, just have a single row, with all the columns.
And if I’m looking to fetch all rows, create a virtual index to sort of fetch specific rows as if they existed.
might be feasible with Query, Relations, and Joined Lists- while remaining lightweight.
@Robert_Petitto any thoughts?
With the right JSON structure, it’s possible for f you wanted to query data… you just wouldn’t be able to display the data as collections unless you created helper tables to parse out the data onto their own row
It’s a lot of work to save rows though. Personally I wouldn’t do 100 columns (or possibly more if you need multiple pieces of info in a “row”).
Hmm, I guess what I essentially need is the ability to list them within collections/list.
So I guess what ended up building are helper tables- and they’re nice and clean, with each table- Customers, Projects etc getting their own table.
I was just wondering if there’s a way to avoid that, trying to push needle and simplify…
@ThinhDinh what do you mean by 100 of columns?
I was referring to this. I don’t like tables with a lot of columns 
I almost always create helper tables for use cases like this.
No no
By all the columns I meant ‘fields’,
Org ID, Org Street, Org Address etc (I hate having many columns, and always try to simplify).
And i wanted to actually having to create many rows within those helper tables.
Do you have a screenshot of the different column in your helper tables?
Helper tables are essentially an an index, correct?
Yes, that’s correct. I usually use it when I have a JSON structure with multiple items, or a comma-delimited list with multiple items. The helper table would include index for each row, and I use that index to access each item in the JSON/list.