3 Replies Latest reply on Nov 4, 2016 3:17 PM by philmodjunk

    Shadow Tables and Shadow Fields


      Could someone clarify the terms "Shadow fields" and "Shadow tables"  ?

      What's the database terminology for the table upon which the shadow tables are based on? Is it "Information Tables" or something else.. ( Other antonyms of "Shadow" feels inappropriate.. sunshine, brright right light...)


      Was watching a past Filemaker Webinar where they mentioned using shadow tables to move "less busy fields" to a separate table connected to the original table using a one-to-one relationship.


      So for example, in a Contacts table with ContactID, FirstName, LastName, DateOfBirth, cAge, cFullName, gSelectedContact

      1. gSelectedContact is to store a ContactID from All Contacts.
        • Is there any advantage of moving global fields in any table to its shadow table other than keeping pure data fields in the "Information Tables" ?
      2. If cAge and cFullName (Calculated Fields) are moved to another table, Will it improve the performance on a layout because filemaker has less fields in the Contacts dataset to load ?
      3. Calculated Fields and Shadow fields are the same ?
        • 1. Re: Shadow Tables and Shadow Fields

          "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.

          • 2. Re: Shadow Tables and Shadow Fields

            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 ?

            • 3. Re: Shadow Tables and Shadow Fields

              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...."

              1 of 1 people found this helpful