How many fields is considered a lot of fields, where it might start affecting performance?
Do data input fields effect performance, or only summary fields, and related fields?
Most of my tables have 50 fields, 100, or a large one maybe 300-400. But I have one table that is approaching 800 fields and quite a few forms. It still works and performs great, but I wonder if I am getting too large, or if people will say, 800? I have 2000 fields!
------------------------------
Mike Tamoush
------------------------------
Question
How many fields is considered *too many* (where it affects performance?)
+14
+22It is not unusual to see tables with 1,000 to 1,500 fields. The fields themselves do not hurt performance.
As a developer it gets a little more annoying to work with tables with more than 1,000 fields just because the field list page seems to load slowly and also when you are building reports or saved the table to table imports those pages take a long time to load due to the for example filter fields or mapping fields because there's so many fields. But it doesn't really hurt performance.
Summary field are more difficult for QuickBase to calculate, but they only need to be calculated if they are being searched or are on a report (or a form). Also if a field were to make use of say a dozen other fields in its calculation, then that field would be a little slower to calculate.
So typically response time is hurt due to the # of concurrent users and their "intensity' of use times the complexity of the app as measured by lots of summary fields frequently used by reports.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
As a developer it gets a little more annoying to work with tables with more than 1,000 fields just because the field list page seems to load slowly and also when you are building reports or saved the table to table imports those pages take a long time to load due to the for example filter fields or mapping fields because there's so many fields. But it doesn't really hurt performance.
Summary field are more difficult for QuickBase to calculate, but they only need to be calculated if they are being searched or are on a report (or a form). Also if a field were to make use of say a dozen other fields in its calculation, then that field would be a little slower to calculate.
So typically response time is hurt due to the # of concurrent users and their "intensity' of use times the complexity of the app as measured by lots of summary fields frequently used by reports.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
Sign up
Already have an account? Login
Login to the community
Login with Quickbase US – quickbase.com Login with Quickbase EU – quickbase.eu
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.