Apps, Performance, and Best Practice
I prefer to have a very limited number of apps, as management can be come quite labor intensive, and I tend to find cross app relationships with some limitations or inconveniences versus staying with...
Forum Discussion
MarkShnier__You
Qrew Legend
Qrew LegendThe Performance is related conceptually by # of concurrent active uses times # of records in the the tables being accessed frequently times the number of summary fields on reports. Those factors hurt performance.
If you do go the route of separate apps, then you cannot make any cross app relationships or cross app saved table to table imports as that just makes it one giant app under the covers. So you need to use Sync tables to replicate master files like customers or warehouses.
If you have many hundred of users like say 500+, then user count can be a factor, probably less than that, less of a concern. tables with hundred of thousands of records like say 200,000+ records can get to be a concern when combined with a high user counts using those big tables.
They keep incrementally improving the performance of Quick Base each year, a bit like Elon's Battery day where there was no magic bullet to announce, but Tesla but is adding up the 5%'s and 10%'s they keep finding to improve the performance.
So assuming no giant reports with killer summary fields and no frequently used tables approaching 500,000 records, you are probably going to be OK. 150 tables do not affect performance. It's the load on those tables in terms of concurrent users hammering away at difficult reports with complex summary fields.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
If you do go the route of separate apps, then you cannot make any cross app relationships or cross app saved table to table imports as that just makes it one giant app under the covers. So you need to use Sync tables to replicate master files like customers or warehouses.
If you have many hundred of users like say 500+, then user count can be a factor, probably less than that, less of a concern. tables with hundred of thousands of records like say 200,000+ records can get to be a concern when combined with a high user counts using those big tables.
They keep incrementally improving the performance of Quick Base each year, a bit like Elon's Battery day where there was no magic bullet to announce, but Tesla but is adding up the 5%'s and 10%'s they keep finding to improve the performance.
So assuming no giant reports with killer summary fields and no frequently used tables approaching 500,000 records, you are probably going to be OK. 150 tables do not affect performance. It's the load on those tables in terms of concurrent users hammering away at difficult reports with complex summary fields.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
Hi Mark,
I'm really interested in (and potentially concerned by!) your comment:
"If you do go the route of separate apps, then you cannot make any cross app relationships or cross app saved table to table imports as that just makes it one giant app under the covers. So you need to use Sync tables to replicate master files like customers or warehouses."
Could you clarify please.
My specific situation is I have a master database (used for content management, and not the fastest due to prolific use of summary fields) and a slave which I update overnight using API_RunImport.
The slave is used to serve read only data to our customers within our web app via API calls).
Are you saying that these two apps are run a single thread because of the use of the import API to refresh the slave tables, and therefore I won't actually be seeing any performance gain from separating the two?
And if this is the case, are you are saying the only way to break this and ensure separate threads for the two apps is for the refresh of the slave tables to be using Connected tables / Quicbase Sync?
Thanks
David
------------------------------
dmlaycock2000 dmlaycock2000
------------------------------- MarkShnier__YouYes, unfortunately when you have a saved table to table import it does create what is called an app dependencies between the two apps exactly the same as if there was a cross app relationship. So that means that these two apps will run in a single thread. It is still possible that your users will have a better user experience with two separate apps but in terms of performance it is identical to having one giant app.They are used to be a suffix parameter that you could use which I will list before but I don't know if it is working today I am just on my iPad and didn't test properly so far this morning. I was up late last night freebasing, oh I meant quickbasing, it's about the same level of addiction.
?a=ListDependentDatabases
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------- Lol.
Thanks for the quick response, although not the answer I was hoping for!
Migrating to using connected tables is going to be nightmare.
Out of interest, when I use ?a=ListDependentDatabases it doesn't actually show the other database / tables irrespective of whether I append this to the master or slave DBID.
Does that mean QB may have changed how these work?
D
------------------------------
dmlaycock2000 dmlaycock2000
------------------------------
