To Store or Not to Store Calculations?

[goldcougar]

We have a table of 179 fields, about 80 are calculations.

Of the 80..

35 are set to automatically create indexes as needed

10 are set to index all

and the rest are set to do not store calculations.

Is there a difference in terms of performance with FileMaker? The reason I ask is because when I defin a new field in that table it takes about 7 minutes for filemaker to finish, after clicking 'ok' to close the define fields dialog and exit back to the regular scrreen.

[Brian C]

The amout of time for filemaker to complete a define field has more to do with the number of records you have stored in your table, than with your calculation fields and if they are stored or not.

When you create a new field, FileMaker has to create this new field for every record stored in your file. This does not occur for unstored calculation fields if you remember to make them unstored before you close the calculation entry screen. In version 6 I know this is an issue, but I am not sure about v7.

Stored calculations are similar to fields that use a "lookup" under auto-enter options.

Their content will only change if data in another field that is part of the calculation has it's content changed.

Unstored calculation fields are more helpful for fields that must always be kept "up to date", such as a person's age. Another reason to use unstored calculation fields is if you are trying to save space and do not want to store the data. The only drawback of unstored calculations is the speed at which data can be searched, summarized, and they cannot be used as a key for a relationship on the child end.

[kenneth2k1]

Is there a difference in terms of performance with FileMaker?

Yes. Stored calculations and indexed fields can take time initially to store/index. But once they have been indexed, it is faster for the system to reference than unindexed and unstored calcs. Unstored calcs only calculate when they are needed, which could take more time when the process is done real-time.