Calculated Fields vs Scripted SetField

[Jarvis]

I know this is a rookie questions because I can't yet cogently explain the relative benefits of stored vs unstored calculations.

I may be getting ahead of myself but I have a more basic question to resolve.

 

A database I am producing for my cabinet shop has a gazillion calculations.

For the most part this is simple arithmetic but there is a lot of it.

We have over 100 possible cabinet combinations and each one of them is built with distinctly different math.

Each cabinet is pulled from a library of possible cabinets.

The final output shows up on iPads in the shop.

 

What I am curious about is the relative efficacy of generating this math as a series of calculations vs scripting the math via SETFIELD scripts and calling the scripts with PERFORM SCRIPT ON SERVER step.

 

If I use the PERFORM SCRIPT ON SERVER approach  wouldn't all the heavy lifting be already happening on the server BEFORE it comes down the tube?

 

 

 

 

 

 

[jbante]

The benefit of calculation fields (whether stored or unstored) is that they are declarative rather than imperative — you don't have to do anything for them to update when you change some of the data they are based on; they just happen, like a calculation in a spreadsheet cell. The downside to calculation fields is that they just happen, and you have limited influence over when to incur the computational cost of evaluating them. This is especially a problem with calculations based on data from many related records, which will be slow, and can happen at inconvenient times. A lesser downside is that sometimes they don't just happen, and it can take substantial study and experience to fully understand when they do and don't update.

 

The benefit of calculation by script is that you have much better control over when (and now where, with Perform Script On Server) the computation happens — it happens when you trigger the script. Scripts can also often organize complicated calculations better than fields. The downside is that when users change source data for a calculation, it's up to you to refresh the result; FileMaker doesn't try to handle it for you.

 

Perform Script On Server offers a performance benefit when your calculations are based on source data that the users are not already looking at, so that source data does not have to be transferred over the network to perform the calculation on the client machine. If the users are already looking at the source data on their screens, Perform Script On Server will not necessarily be faster, and may even be slower. Servers are usually higher-powered computers than client machines, but servers also have a lot of other processes on their minds; and communicating with the server happens over a network, which is the slowest bottleneck in the whole application.

 

I don't know enough detail about how the calculations work in your particular solution to be able to suggest what set-up is likely to be fastest. Even if it did, the advice would probably boil down to the same thing anyway: test all the combinations you can think of, and use the one that turns out to be fastest.

[Jarvis]

Thank you so much jbante.

That was a very cogent & nutritious response.

You helped me a lot!

[LaRetta]

... nutritious response.

 

consider that stolen.  :-)

[comment]

consider that stolen.  :-)

 

I like this classification too. Perhaps we could expand it and categorize some posts as "low fat", "no sugar" and "0 calories"?

 

Oh, and "high fiber" of course...