App Viability Question

[Ryan_Wagner]

Hi, all. This is my first post here.

I experimented with my first app - a very minimal inventory app for work supplies - a year ago, but now I’m wondering about a much bigger app idea. I’m hoping I can describe it in some detail here and find out from folks in this forum if it would be possible to make with AppSheet…

So here goes…

I am wondering if I can make an app that will allow me to

1. Have pins representing all the storm drains in my county.
2. Be able to have my crew click those pins and (with a “quick edit”) log whether they were dry or needed a treatment.
3. Depending on what those drains were treated with, set a return appointment date for those drains and have the associated pin change colors.

All of these drains already have lat, long information and names (numbers assigned.)

I’ve gotten as far as being able to plot about three hundred of them, but my biggest questions are:

1. Can AppSheet handle 200,000 rows of these? I have seen elsewhere that 100,000 is the limit, but perhaps there is a workaround? Or I could even make separate apps for the same purpose to split up the areas, I suppose.

2. Is there a way to not only have the existing row edited (e.g. logging that an inspection occurred) but be able to “keep” the record of this elsewhere? Like another table/sheet?

Has anyone built something like this? I’m new to this platform, but seeing loads of potential. I’d hate to be sidelined by the scale of my needs.

Thanks for reading all the way through!

[Marc_Dillon]

Ryan_Wagner:

I am wondering if I can make an app that will allow me to

1. Have pins representing all the storm drains in my county.
2. Be able to have my crew click those pins and (with a “quick edit”) log whether they were dry or needed a treatment.
3. Depending on what those drains were treated with, set a return appointment date for those drains and have the associated pin change colors.

Yes, those are all easily possible.

Ryan_Wagner:

Can AppSheet handle 200,000 rows of these? I have seen elsewhere that 100,000 is the limit, but perhaps there is a workaround? Or I could even make separate apps for the same purpose to split up the areas, I suppose.

200k would be a bit much, but it also highly depends on how many columns you are multiplying that by. Please see these articles, and maybe do your own searches here on the community about the subject to learn more.

G Suite Tips

Google Spreadsheet limitations | G Suite Tips

Google Spreadsheets are extremely powerful and convert very well from Excel, but they do have some limitations: Up to 5 million cells for spreadsheets that are created in or converted to Google Sheets 40,000 new rows at a time Maximum number of...

help.appsheet.com

Limits on Data Size

How to design your app with consideration of caching and intermittent connectivity.

Ryan_Wagner:

Is there a way to not only have the existing row edited (e.g. logging that an inspection occurred) but be able to “keep” the record of this elsewhere? Like another table/sheet?

Absolutely. I’d recommend a child Table, referencing the main Table that holds all of the storm drains, to hold all of the inspection records.

[Ryan_Wagner]

That’s all great news, thank you for the detailed response.

Looks like I have some research to do. I’m hoping I can have something ready by early next year.

Maybe someone who has created something like this will stumble into this thread…

[Austin]

There is also some oddities on the limitations when it comes to databases as we have tables that near 70MB in the database, 300k rows with 21 columns but we don’t seem to reach the 5/10MB data limit.
Databases definitely allow you to get around a good bit of the size limitations although they do have a much higher cost.

[Ryan_Wagner]

That is encouraging, thanks. What I’m after seems pretty simple compared to some of the advanced topics I see in this forum, but I’m very new to it.

[Ryan_Wagner]

@Austin_Lambeth @Marc_Dillon This is an old thread now, but in the month that has gone by, I have gotten a good portion of my app up and running.

I’m currently at 52,000 rows of a table full of storm drains, with about ten columns of information on each. By far, the most amazing thing about this platform for me is that the app only loads the immediately relevant rows in the map view. That plus the clustering option has kept it moving great.

I’ve set up multiple actions for the storm drain inspections, I have those actions create a new row in a separate table using a bot, I’ve added kml boundaries to the map to designate work areas, and I’ve set up new information on a separate sheet used by another department to populate one of my tables using Zapier…

It’s really only interesting to me, of course, but I thought I’d drop in for an update. This is a great program. Now I’m slowly ratcheting up the total of rows of drains that I need to 200,000…Holding out hope that this thing will stay nimble…

[Austin]

Another performance scalability tip is historical tables. After the point where a row needs to be loaded you can either filter it out of the app using security filters which generally increases performance or if they are not ever needed again you can copy them to a separate table that is used in a different historical viewing app. That’s how we keep our invoicing apps “fast”, we only have about 200-300 invoices at a time and all historical apps go to a secondary app that we don’t really care if you have to wait 30 seconds for it to load.