Initially I created an application with a plan in the core. After it was finished, it ran well. Once it was finished and there was data coming in, around 10,000 rows, the appsheet could be said to have stopped.
Because with spreadsheets the performance was bad, it couldn't use Security Filter, I changed to using mysql.
After it was done, I went into deploy mode, it turned out the account was an error. CORE can't use mysql. This means that Core can't use security filters.
My conclusion for now, appsheet is a platform for small class applications. When starting production, it is clear that we need a large database, spreadsheets are not capable.
Disappointed with appsheet, even though I was making an application for a scale of 1 country.
If it is like this, then it is better in a prototype position with copy copy of the application.
@appsbkhit wrote:
This means that Core can't use security filters.
Yes Core can and does use Security Filters. The way Security Filters are applied to sheets versus databases is slightly different.
For sheets or similar sources, the the data is loaded into the services and then the Security Filter is applied BEFORE the data is downloaded onto the device.
For databases, Security Filters are ATTEMPTED to be applied to the database itself. This provides slightly faster read times since only the filtered data is loaded into the AppSheet servers. HOWEVER, not all Security Filter expressions are directly translatable to database-side SELECT() statements. So it is is still possible that a portion of the Security Filter expression is applied to the AppSheet servers BEFORE downloading the data to the device.
@appsbkhit wrote:
CORE can't use mysql.
Correct! Database connectivity requires an Enterprise level plan.
@appsbkhit wrote:
When starting production, it is clear that we need a large database, spreadsheets are not capable.
This depends on the amount of data AND what users need to actually see/use throughout their daily routine. AppSheet can provide excellent systems for large data-driven apps with some care in how its built.
I will first say, if you are willing and budget allows, use a database when you have a large or fast growing dataset!!
Regardless of what you use as a datasource, you should think of your app(s) as a WINDOW into the vast amounts of data collected. There is rarely ever a need for a user to look at thousands of records each day. So the apps should be designed with extreme scrutiny to display to the user only what is necessary for them to do their job.
For example, if they occasionally need to look at history, then provide a function to handle that. If the thousands of records need to be summarized so the users can view summarized results, then a process on the backend should be used to build those results and only the results pulled into the app.
There are many other such techniques to reduce the data actually pulled into the app to keep a consistently performant app.
I hope this helps!
My DB has 12 table. 5 tables have about 6000 rows a month. So, gsheet is not reliable for this app.
User | Count |
---|---|
18 | |
10 | |
8 | |
5 | |
5 |