Performance cage fight: Stored Calcs vs Static Fields - Who wins?

Discussion created by jmedema on May 17, 2016
Latest reply on May 19, 2016 by erolst

A colleague and I are having a performance-related disagreement about the relative merits of two different field types: Stored Calculation fields versus Static Fields.


Here's some of what we know:

  • Fields that have a field type of Calculation can be stored IF the values in the calculation are pulled from functions (i.e. Get ( CurrentDate ) or fields within the current table.
  • If a calculation references data stored in any other tables - related or not - the calculation cannot be stored and is considered an "un-stored" calculation. Unstored calcs take longer to render and can be a performance hit on larger solutions, over WANs, etc.
  • Both Calculation fields and regular Text, Date, Time... fields can be indexed and used in relationships


My preference is to create regular static fields and use the auto-enter feature in field options to populate the field. In a relatively recent FileMaker Talk podcast I heard one of the Matts (Matt Navarre, I think) say that he's eliminating the use of calculations wherever possible, which bolsters my opinion here.


Screen Shot 2016-05-17 at 9.40.49 AM.png


My colleague's preference is to create a Calculation field because he likes seeing the actual calculation in Manage Database > Fields.


SO, the question is this:

If the two field options listed below were in a cage fight based on performance (rendering speed, etc.), who would win and why? Are there any other benefits to one field type over another aside from performance that should affect our decisions on which one to use? (The fields below have the same resulting value and, no, I wouldn't create a solution with both of the fields since I only need one)

Screen Shot 2016-05-17 at 9.55.13 AM.png


What do you think?