How do Container Field Repetitions impact server performance?

[Jarvis]

I have a question about how much overhead is associated with referenced container fields.

 

I have a Global container field [Library] with 100 repetitions,   Each repetition holds a picture of a kitchen my cabinet shop produced.

In a second field is a number field [Kitchen] that is populated with a dropdown list containing the values 1-100.

A third field [Picture] is calculation field that has a container as it's result.

 

The calculation is as follows:

Picture=GetRepetition(Library;Kitchen)

 

If only one picture at a time is being served what happens to the weight of all the other pictures?

Does the fact that they are available for reference increase the amount of data that must be served or the only thing coming across the server just the one repetition called for in the calculation?

[LaRetta]

Assuming you store these fields in a one-record Globals, Preferences or Admin table (if the Picture unstored calculation exists in multi-record table, all bets are off):

Fetching
The Picture calculation will be unstored since it references a global field. All fields (or repetitions within a field) of that single Preferences record will be fetched and the calculation then evaluated on the client side.

Rendering
Since you display the Picture calculation (with a single image), only the single image will need to be rendered when the layout is redrawn.

I think it might be more efficient to use a Kitchens table with your 100 images as records. You then place a gKitchenID global in your current table (such as Dashboard layout) for User selection from your drop-down (of KitchenIDs). Relate the tables:

Dashboard::gKitcheID = Kitchens::KitchenID

This constricted relationship fetches (and renders) only a single record from your Kitchens table. The User may only look at 3 images - they probably won't want to look at all 100 of them so why fetch them all? Do not display the Kitchens table with any fields on its layout (which will cause pre-fetch of 25+) but instead display kitchen images only through 'parent' tables - singly by this strict user-specified relationship. Some might suggest using a portal to Kitchens from which to select their description and for setting the gKitchenID but a portal will pre-fetch the number of Kitchen records matching the portal row and if you sort it, ALL Kitchen records would be fetched. By using a value list (all values), no pre-fetch is necessary and you only download and render a single record when chosen.

There surely are other approaches but I would not set this up so all images are fetched at once (in a single record/field) unless you plan for the User to (very high-percentage of time) view them all. The assumption is that these images are high-quality, beautiful kitchens and not simple icons. Admin icons are loaded into repetitions at times but they are used throughout a solution and are (should be) very lightweight.

 

Drop-down allows jumping to typed values otherwise scrolling 100 values would be PIB.  Value lists of 25+ are sometimes moved to portals but I suspect it would be unnecessary and inefficient in this case.

Edited March 12, 2015 by LaRetta

[Jarvis]

Thank you LaRetta,  

I will  have to digest  (and experiment with) this for a while.

[Jarvis]

LaRetta's recommended method of accessing kitchen images through a related table works very well.

I am still, however, a little bit confused about how to display these kitchen images only through a 'parent' table.

How would the table occurrences look different than I have them in this file?

 

The library of images has to live somewhere.

How do you get access from the current table to the library table with a blank layout?

 

 

testlaretta.fmp12.zip

[LaRetta]

How you have it set up is exactly what I suggested.  :-)

 

By selecting the kitchen to display, only the single image is fetched for the User instead of a single record/field with 100 images.  If there is additional functionality you are missing, let us know and we can help you further.

[Jarvis]

Now I understand what you are talking about.  This approach has only one image that has to be served as opposed to one file with 100 images that have to be drawn.

Thanks LaRetta!