Different Tabs vs Separate Workbooks

[Gustavo_Leiva]

Hello,

I am building a app with a significant number of rows. Since it goes over the 100,000 rows, I split the data into different days an operation/service will run by. One app per day of the week. All 5 apps tap into a single workbook with separate tabs per day.

My question is if I am going about the best way to achieve the best performance possible or I should give each tab their own workbook. I can not recall where I read where it is best to limit the number of unused worksheets/tabs in a workbook because it will hinder app performance. If this is true, should I use different workbooks instead of worksheets/tabs to host the data?

Thank you very much for taking time to read my inquiry.

[WillowMobileSys]

Gustavo_Leiva:

I am building a app with a significant number of rows. Since it goes over the 100,000 rows,

Many apps keep this much (and more) data around for historical reasons only. The very first question to ask is:

Does the app need ALL of these 100,000 rows for the day to day use? Be honest with yourself in answering.

If the answer is no or those older rows are looked very infrequently, then I would recommend using Security filters to reduce the number of rows loaded into the app. No breaking up of app or data required.

Then you can build a “history” app to work with the older records if needed. I would make this a very simple app to allow review of the old records. For anything that may need an adjustment, I would introduce an editing flag (a Security Filter bypass flag) that allows this history row(s) to be pulled into the main app temporarily to take advantage of the app functions to make adjustments. When done, turn the flag off to prevent inclusion upon next Sync.

If your answer is YES, you absolutely need all 100,000+ rows for daily use - well I would ask WHY? as that may lead to a different suggestion to help reduce rows. I’ll wait for your reply before proceeding further. It can get quite involved from here.

[Gustavo_Leiva]

Thank you for replying! The answer is yes. This app is a one time thing and only for a week. Essentially, what we are using the app for is to track the progress of a deployment of deliverables(Delivery Complete,Skipped,etc). Instead of having the one table hold all of the accounts in one spreadsheet, I separated the accounts that are going to be delivered to by day, in hopes that it will improve data sync performance. Once a day is done and data has captured the status of an account deliverable, the app for that day will have served its purpose. Each day of accounts also have their own table/spreadsheet that hosts those accounts’ deliverables/products.

I also want to add, the reason the 100,000 rows is an issue is because google sheets or appsheet has that number of rows has its cap for google sheet. Whenever I tried creating a table with over 100,000 rows, I receive an error message from Appsheet. So that is the main reason why I have the data separated into many a spreadsheet per day for the 1 week. Have the workbook hosted in One Drive.

[Steve · Accepted solution]

help.appsheet.com

Scaling Using Data Partitions

How to use data partitions to improve performance at scale.

[Gustavo_Leiva]

Will research this concept and circle around if I have any questions! Thank you!

[Gustavo_Leiva]

Thank you Steve and @WillowMobileSystems for the help! Think this is exactly what I was looking for. By partitioning, I can exclude those days that I will not be needing anymore accordingly, thus having the app not pull irrelevant data back and forth and increase app performance. Thanks again for your help!