One Big Anchor Buoy

[ryangrg]

I have been playing around with a design pattern utilizing a table for storing layouts with everything else buoyed out. My question is in regards to performance. If I have 80+ tables with a few running several thousand records and growing Is this a bad idea. I would have less tables on the graph but more loading I presume of unnecessary tables on layouts that don't utilize them. Anyone, think I should avoid this strategy? Some layouts will have a thick patch of Tab Panels too, does related information get requested only when it is viewed? Not sure what goes on under the hood, some fead back would be greatly appreciated.

[Vaughan]

A table for storing layouts? You mean layout names?

[ryangrg]

Yes layout names, but not just the name other stuff pertinent to the layout and who the user is also. Basically when you change a record a script trigger changes to the appropriate layout based on the layout names field. But mostly information for customers, suppliers, or whatever can be switched through tab control tool without changing the layout.

[Vaughan]

What would the point of this be?

[Kris M]

Great white paper on the subject of graph modeling.

http://developer.filemaker.com/content/technet/pdf/approaches_to_graph_modeling_en.pdf

[Vaughan]

I'm sorry, I don't make the connection between a table containing layout names and different methods of structuring the relationship graph.

If you read the article you'd have noticed that the a-b model is NOT the most efficient.

[ryangrg]

My goal was to have less layouts, but then I just end up with a huge stack of tab controls that becomes a nightmare to edit. I'm ditching this idea. I've read the white paper but I never had time to figure out a way of getting around anchor buoy for certain techniques. Must notably, I make heavy use of the technique laid out in Lesson 9.3 of the Filemaker Training Series (for FMP 10), Portal Row Highlights & Preview Panes. I also further build upon it to have the preview pane highlight to reveal another preview pane sometimes going three to four tables deep. For example if you have a customer with multiple addresses then you want to show data related to different addresses as well. Furthermore, you may have contacts related to customer then to the address then info on that contact, needless to say the graph sprawls out big time.