A question for the old experienced Glider

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.

Pease advise if you can.
Thank you

Have you looked into having a row for each unit, and then use columns for your static checklist?

1 Like

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.

Thank you for your respected reply, time and effort.

The case is as follows:
Categories contain 16 row parent table.

  1. Masonry work
  2. Plaster work
  3. Internal finishes
  4. Electrical

Then each category has child around 25 child for each parent item.

The chilld items will appear when the user selects their dedicated parent only.

So if the user choose the masoney work thin the user will see related child to masonry work and so on.

User will not see the 400 columns.

If number of columns would not be a serious issue to Glide mechanism, then i will take your kind advise and try to adopte it to fit my case.

Really thank you so much.

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.

Appreciate your advise.

Thank you.

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.

Then, merge them together in separate sheet.

I’ve done something similar to this.

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.

Good morning @Darren_Murphy

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.


Good morning @kingzy,
Appreciate your kind advice, However, we will end up having the same number of Rows.

in fact i am thinking in how to allow clients to retailor the entire checklist.
Thank you

You should be able to do all of this with just 1 row per flat–1020 rows. Make a column for each checklist item.


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 :bouquet:

You could create a separate app for the realtors to check using row owners with the new combined data, that way the app doesn’t load all the rows.

So that’s 1 app for inspection and another for checking.

If I get you correctly.

1 Like

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. :pray: :bouquet:

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.