A simple concern / question

[Pratyay_Rakshit]

I have almost 45 tables in my app (which, though starting out as an experimentation project, is now turning out to be an ERP for our construction firm), 10+ slices and counting. Some of them have exceeded 2000 rows. There are prospects to increase the number of tables in future.

So my concern is, to what extent can I keep adding tables to the app, before it starts becoming a problem? As of now, based on my current expertise, I can not eliminate tables that are already there in my system, though I surmise that such provisions can be made.

[Kirk_Masden]

Good question. I don’t know that answer but I’m looking forward to reading what others have to say about this.

[Marc_Dillon]

That’s how it usually goes, you start off experimenting, then just keep adding and adding as you get new ideas.

You could consider a full redesign before you start to go even further. Now that you’ve used Appsheet for a bit, you know more about how to do things than when you first started. Try to come up with better ways to accomplish your goals, better ways to design your data structure, less virtual columns and more real column formulas, etc.

Try to think of places where you can split your app into different apps. Where are there clear lines of separation between groups of tables with no, or very little, reference connections? Split these groups of tables into their own apps.You’ll get smaller and faster apps.

Another thing to think about, if you’re going to be generating a lot of rows. Is there any way that you can “retire” some records after some amount of time? You can delete old records, or if you still need them, move them to a read-only table, possibly with no virtual columns.

[Steve]

Pratyay_Rakshit:

So my concern is, to what extent can I keep adding tables to the app, before it starts becoming a problem?

There is literally no way to say. It’s entirely a function of all the factors involved, including: data set size, data growth rate, data organization, data store type and performance, virtual column use, security filters use, data partition use, concurrent users, common usage patterns, and many other things. The best you can do is test.

I agree with @Marc_Dillon that you might be well served to split your one large app into several smaller apps, and that you would probably benefit from deleting or archiving old rows to reduce the data set size.