So, I am concerned about App bloat. I want t...

[Kevin_Richard]

So, I am concerned about App bloat.

I want to take in customer information, customer orders (which have details), and then the line item details of those orders. That’s three tables as I see it now, with that final one growing very fast (is that going to be a problem?).

Then I also want to be able to build a purchase order section of the App.

This would take the order details table and look at a column for “Ordered (Y/N)” and display it on a page of the app where a user can go through and check it off once the order has been placed.

I’d like that to generate a table with the Purchas Order name as well as what was ordered, the date, and what vendor it was ordered from.

This would be a 4th table that would also grow large.

Then I need a production workflow section of the App that would track the progress of the order through its various stages of production (4-5 different tracks it could take).

So that’s another 4-5 tables for each stage of the workflow that would allow us to check off/timestamp? when a task was completed (this seems simple enough data wise).

Potentially, I would like to also log job performance metrics at some point.

They could hit a button when starting the job and then hit a button when finishing the job which would log how long the job took so we could track time performance which would help with scheduling jobs.

I have (I think) one other

task I’d like incorporated in this app that would track an inventory of tools that get tied up on jobs while they are in progress and have various statuses (Clean, Prepped, On Job (job id), dirty, broken).

So, I am looking at that and feeling like that is a LOT of “functionality” to incorporate into one app.

Is that correct?

Should I break out the App into two separate parts?

A front of house app that deals with the orders/customer data and then a production app that deals with order progress, time tracking, and tool status.

Or should I break that up even further with some of those things?

I just worry that the app will be bogged down if I try to do too much or it will be just too much to manage on the development side.

What are you guy’s opions?

[Levent_KULACOGL]

@Kevin_Richard what’s the account plan of your app? Per user or per app? I mean is it a public app or user authenticated app?

[Kevin_Richard]

@Levent_KULACOGLU, I’m just prototyping right now.

Probably just per app as we will likely be all logging into the same account.

[Levent_KULACOGL]

@Kevin_Richard when you have a fastly growing database, it’s a best practice to: 1.) Use a security filter to filter the amount of data to be displayed and processed at each sync (requires a per-user plan) OR 2.) Back-up and delete the historical data from the base sheet as there won’t be a security filter in per app plans.

Otherwise, by-time when your data grows up, you will be having long sync times with your app.

On the other hand, provided you are planning to use gSheet, than you shall also consider that gSheet have a data limit up to 2M cells. This 2M is considered to be text only and provided you have complex sheet functions or external functions (i.e. IMPORTRANGE, GOOGLEFINANCE etc.) this amount drastically decreases.

Therefore, depending on your data projection calculations, I can humbly advise you to use SQL as a database sourse

[Kevin_Richard]

@Levent_KULACOGLU Thanks, that is EXCELLENT points and advice.

I imagine I could archive some of the older data pretty easily if need be as there would not be much need for a lot of that information once the job is complete.

As of now all this stuff is tracked on paper forms and then just stuffed in a drawer later.

I was thinking gsheets due to simplicity but I am SLIGHTLY familiar with SQL.

How much more trouble is SQL to setup and use in appsheets?

[Levent_KULACOGL]

@Kevin_Richard you can use many SQL sources like Azure, Google Cloud SQL, AWS etc. but I can propose Google Cloud SQL w/MySQL for its ease of managing. You also have the flexibility of structuring your app base with gSheet first and then simply choose to copy that app to the SQL instance that you have connected to your AppSheet account. You may find this help page useful I believe: https://help.appsheet.com/data/using-different-data-sources/copying-an-existing-app-to-a-sql-databas... help.appsheet.com - Copying an Existing App to a SQL Database