Jump to content

Summary Fields vs Calculations of related items


This topic is 6242 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Is there any speed differences between using a summary field verses a calculation that uses aggregate functions such as count and sum? What are the pluses and minues of using either way? If I end up using the seperation model I think that summaries are the way to go because its less relationships for the data file because I can just use summary fields with relationships I make with the layout file. Is this your experience?

Link to comment
Share on other sites

On large databases aggregate calculations will slow things down, summaries are by far best for reports utilizing the sub summary parts of a report with the summary fields. If your solution is small (record count) it won't make a big difference if you use aggregates, sort of depends on what you want to do.

Twd: there is a group of calculations called aggregates that perform calculations across a set of related records.

Rod

Edited by Guest
Link to comment
Share on other sites

No what I mean is what are the pluses and minuses of the two different setups if for example there is a customer table and a related donations table. I could use a summary field to figure out the donation total for each customer. I could also use a calculation field with Sum(DonationAmount) in the customer table. Is one better than the other? What if I wanted to use the seperation model.

Link to comment
Share on other sites

In general, if you generating a report in preview mode to view these sums and group your report by customer, you would use summaries, if you have a layout in browse mode with a portal that lists all the donations of a particular customer, and want to know the total, say below the portal an aggregate would be used. This is a general way of looking at it.

Link to comment
Share on other sites

The problem here is that related summaries kind of work, but isn't documented ...and have substantial freshing issues. Newbe's are slower to recognize aggregate functions, of to me unknown reasons.

But it have often been, that the relational approaches that filemaker have implemented not fully are embraced, and a solution where er slow summary are expirienced is a result of a trial-n-error kind of development, where a substantial part of the utilizations are trying to pull filemaker out of it's realm into being a spread sheet instead.

But as it is, are the "aggregates" meant to deal with found sets relational established, belonging to say a portal, while summaries are meant to deal with all kinds of measures of records, but only in summary reports or live presentataions in header or footer area in browsemode, while aggregates over a cartesian type of relation are bound to be much slower the more records involved.

However if the task is to give the figure of an account, with zillions of records of financial transactions aren't none of the above particular usfull, due to the burden the calculation engine are likely to recieve in busy accounts. Here should the venetian principle for ledgers instead be used:

http://en.wikipedia.org/wiki/Luca_Pacioli

http://en.wikipedia.org/wiki/Double-entry_accounting_system

Because any summing only deals with the sum from the previous record, and changes or deletions of records from previous transactions are illegal and in fact "cooking the books" - the system was crutial to merchans it was intended for ...because it gave what today would be called dashboard'ish for instant eyeballing how much the merchant was worth and what deals he then could undertake. This was from a time where any kind of non brain based computation were availiable at all.

There is an example of this principle here:

http://www.filemakerpros.com/LULAST.zip

So as ever, is the answer to which is best - it depends on the task at hand, however should following article's points be considered:

http://www.onegasoft.com/tools/fastsummaries/index.shtml

...and if the point is never to leave browsemode, checkout this template that builds on these foundations:

http://www.kevinfrank.com/download/kf-fast-summary.zip

Further more is there great inspiration to get from studying this template:

http://www.kevinfrank.com/download/repeating-lookups.zip

...and this article:

http://edoshin.skeletonkey.com/2006/12/crosstab_report.html#more

--sd

Link to comment
Share on other sites

Ah, my personal opinion... Use calcs for calcs in browse / preview mode, use summaries for summarizing information for reports -- especially sub summarized reports where their properties become unique, it's pretty straight forward.

If you put summaries in browse mode... It will substantially start slowing down at a later stage... the field will summarize any time you enter the layout, sort records, whatever... you may not notice it with a hundred records, or even a thousand, but you will start to notice it after that (and much earlier if you're in a network or WAN environment)

Edited by Guest
grammatical errors
Link to comment
Share on other sites

Again what about those that use the separation model. Does it not make more sense to use summary fields and then just reference them from the parent table like in the file I posted? This would get away from creating all those extra relationships for aggregate calculations in the data file.

Link to comment
Share on other sites

I do use the seperation model, and like it or not, you can't get away without using calculations -- one of the main benefits is that your data calculations don't clutter your interface. The only real use for summary fields is reporting .... Think about the name "summary" it can only give you so much information.

Link to comment
Share on other sites

The only real use for summary fields is reporting

Hear - hear!!! I've seen countless templates from newbee's who can't keep thier fingers away from globals and summaries, they are among the 7 deadly sins of novice development ranking almost as high as the use of repeating fields are....

Which of the starter templates endorses these bad habits? It's about time they get removed due to an offical complain ...if it's so, or if we could get a hint as to what other application's habits that makes this so tempting to commit??

--sd

Link to comment
Share on other sites

I whole heartedly agree with what was said above, also make sure you are aware of the GetSummary function, with this and normal summaries you are set for reports, and use the aggregates with care on very large found sets or a complete table, they can really slow things down.

Link to comment
Share on other sites

This topic is 6242 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.