to be Honest, it is not a question related to Glide functionality. in fact it is more related on a way to reduce the required No. of rows on Data itself.
First things first, I m working on creating a solution for construction inspection targeting Middle East region.
i have list of projects, some projects contains almost 1020 flats, and i have a check list for many items like masonry work, plaster work, etc.
Lets take the Masonry Work as an example:
I want the inspector to mark that he inspected each item in this checklist (almost 24 row, just for Masonry Work) for every unit of the 1020 unit for each project. The checklist itself will not change from unit to unit, it is fixed for all units.
If i linked each unit to the list i will end having almost 24500 row in one single table for Masonry work only. we didn’t mention the plaster and internal other finishes, etc.
i really need a find a way to minimize the impact of such table to Glide data.
Actually, if i am using Mysql then i don’t have this limitation. but i loved the Glide interface, and really want to build my set of modules using it.
First, Thank you for your kind reply.
i have almost 16 categories, the Masonry Work is one of them. Let us assume we have average of 25 point to be checked doe every category out of the 16, then i will end up with nearly 400 columns. is that heavy load to Glide?
really i don’t know
Just trying to understand your scenario a bit. What are the 25 checkpoints for each category?
In the example, Masonry; are there 25 different points to be checked on that masonry job for each of the 1020 units? I know people have had 100’s of columns with no issues, but just trying to understand the need to give the best advice to how to translate into a table. 400 checkboxes seems excessive just from a screen-management point of view on a handheld device.
So you’re really dealing with multiple projects; each of which can have 1000 flats; which each can have 400 items done (or not done)? We’re talking about a massive amount of data.
Precisely, this is a vision to what will happened when i issue the inspection module to be officially used. You are absolutely right. Thats why i asked a help from experts.
Yeah, I agree with you here. I have seen @Darren_Murphy coming up with some apps containing a huge amount of columns, I don’t think there’s a really big issue with that.
However, for the end user, is this just too much for them to go through, though?
You could break up the columns into several sheets, so instead of 400 columns in a sheet say 40 to 100 a sheet. That could mean you split the inspection into several segments.
In my use case, I have lorry drivers that need to perform a safety check on their vehicle before they start a shift. There is a list of 20 items to be checked, and the check is done about 300 times a day. If I was to save each as a distinct row, that would be around 6000 rows per day, which obviously wouldn’t scale with Glide as it currently is.
So the approach that I took is to only log the fact that each driver has performed the checks, plus any exceptions. They still see a list of all 20 checklist items, and they are forced to check them off one by one, but no new rows are generated unless there are any failures. Here is what it looks like in the UI:
If they mark any items as failed, then at the next step they will be asked to comment on the failures and will have the opportunity to attach a photo. It’s only at this point that a new row would be generated. So instead of 6000 extra new rows every day, it’s just a handful.
Good morning @ThinhDinh,
Really Thank you for intervening in this conversation.
The Engineers were used to perform such checklist on paper, However, I planned just to have an action button to mark the entire checklist at once, if all points were passed. or in other scenario they can check all by a button then manually mark the failed points. Personally i used to do that by myself when i was young, but using excel then later on using Microsoft Access.
As usual, positive approaches, always with your signature. Thank you.
i will think in your respected solution and try to find a way to incorporate it to fit my case.
Meanwhile, and in this point i am not comparing Glide to Appsheet where a came from, but Appsheet is using something near to User Specific Column USC, called Security filter.
We can Suggest to Glide to use the USC in different wider approach or cases. for example, we can restrict and filter the data downloaded to the user device not only based on his email or his own data, but we can extend that to be based on specific condition, in my case, the user can see only the projects shown in user table under role or something flexibly determined by the app developer.
i think that will open a new opportunities to the USC column, in fact we could rename it differently on that case.
Really thank you for sharing generously your respected valuable experience with us her in the community.
That’s great information, So Glide has no issues with Columns but Rows. i will re adjust my way of thinking based on that. i was thinking to solve it as database perspective.
Thank you really for that information and clarification. Good morning
Honestly, i didn’t get your exact point, but what i understood is to split the apps, in fact, i am using Glide pages. However, the inspection itself by definition is to check those points. if he didn’t do that checklist then he didn’t do the inspection itself.
regardless if he wrote it in paper or just check them visually with no record".
really thank you for thinking and sharing your ideas with me.
