Hiya - I'm working on a solution that uses a fair number of summary fields. As a result, the total field count for the primary data table is higher than I'm used to (currently 35 fields). Normally I keep my field count very low and try very hard to normalize my data. One reason to do this of course is that when evaluating a found set, every field in a table's record is downloaded from server to the client. Having skinnier tables means less bandwidth gets taken up.
My question is this: are summary fields also part of this equation, or even unstored calculations? And are they re-evaluated for every record in a given found set? Ordinarily I would never have unstored calculation fields or summary fields, so I have no experience with performance issues, especially where there is a lot of data involved. In this case, the summary fields are (really well) integrated into dynamic sub-summary reports; otherwise I would use the calculation engine to aggregate whatever data I wanted summarized.
Hi @dutchman,
It is not straight forward yes or no.
Calculations are not made in advance, nor are summaries. If these fields are not displayed, then they are not calculated. In that situation they don't have significant overhead.
However, if they are displayed then it is necessary to calculate them. If the summary and the calculations are based on data stored in the table then nothing more is needed. If the summary or the calculations are based on related data, then the extra records need to be evaluated and loaded.
1 Like
Thanks so much for the quick and helpful reply. I've actually made a widget for testing the speed of scripts and formulas, so I'm doing a little experimenting to see where these unstored "fields" might slow things down, especially where FM server is involved. I suspected as much about whether they would need to be calculated, but my years of having only around 10 fields per table makes me uncomfortable with having 35, even if many of these are "inert" from a calculation perspective. If I uncover anything interesting I'll post it here. Have a lovely day!
I'm a big fan of putting calculations into the UI where they are required rather than having them in tables. There are text calculation objects in the latest version, though button bars do this already.
1 Like