"Shadow table" is a term I've seen used only to identify the FileMaker Entity that is linked via ESS to a external ODBC data source.
That doesn't seem to be what you are describing here as this isn't a case of moving "less frequently used fields" into a related table. Never seen that identified as a "shadow table" as this would simply be a related table linked in a one to one relationship and is used to produce "narrow" tables as a way to improve system performance.
Thanks for the explanation. I thought shadow tables were tables in the "shadow" of a main table, its records were "hidden" from a layout based on the main table.
I have a table with 10 data fields and about 22 calculated fields. From a performance POV, is it advisable to move the calculated fields to a "narrow" table ?
1 of 1 people found this helpful
There are way too many unanswered questions to be able to answer that.
Are these fields that only need be used in rare circumstances?
Are these calculations stored or unstored?
If unstored, do they need to reference large numbers of related records each time that they evaluate?
Is this a sever - client set up over a WAN? Are the clients web clients, citrix clients, FileMaker Pro clients or FM GO clients?
If they are all stored calculations, there's little be be gained in most cases. Likewise, there's no point in moving them to a related table in a one to one relationship if you have to put that field on nearly every layout anyway. Unstored calculations that only need reference a few related records will have some negative affect but over a total of twenty fields, it again is not likely to be a large factor affecting performance.
The basic fact that narrow tables tries to leverage is the fact that when you put even one reference to a field into your solution, FileMaker Fetches the entire set of fields from the same table. The more fields defined in that table, the more data being fetched to the client. Make that a 1000 field table with 1000's of records in your found set and this can be a truly massive amount of data. My favorite word picture for this is "trying to empty the pacific ocean with a single soda straw...."