1 2 Previous Next 17 Replies Latest reply on Oct 14, 2016 9:24 AM by fmpdude

    Relationship Design


      I've noticed my relationship graph getting a bit out of hand.


      As you can see its pretty messy with a lot of table occurrences. Will this affect performance later down the line?

      Is there anything I can do to tidy it up without a complete system overhaul?


        • 1. Re: Relationship Design
          Johan Hedman

          You have build things in TOG (Table Occurrence Groups) like you are supposed to, but I would take of the relationships that goes from each TOG to another. That would affect your solutions performance.


          To make things easier to look at I would recommend you to have it setup like this


          HEADTABLE -<headtable_SUBTABLE



          and keep on building from left to right. This make things easier for you to look at

          • 2. Re: Relationship Design

            Is this easily do-able without affecting scripts and layouts?

            • 3. Re: Relationship Design
              Johan Hedman

              Changing relationship name would not affect any scripts or layouts.


              If you take away relationship between your different TOG you should first run a Database Design Report and import your report into Base Elements/Inspector Pro

              BaseElements | Goya Pty Ltd


              to make sure you dont use that relationship. If you use it, then you should create a relationship within that TOG


              I have a grand rule that my relationship diagram for each TOG should not be more then max 5 steps away. In your I can currently go a lot longer than that

              1 of 1 people found this helpful
              • 4. Re: Relationship Design

                Snipping the links between the major TOGs is not simple. You have to ascertain when and where the TOs are referenced in scripts, layouts and table definitions. You also have to decide how to replace the functionality. That would mean new TOs, new relationships. It would also mean rewriting the scripts and replacing layout objects, etc.


                It could be a lot of work. I would not undertake it unless I had sufficient reason to do so. Performance pain that might occur sometime down the track is not a sufficient reason, in my opinion.

                • 5. Re: Relationship Design

                  I think i might leave it.


                  As this database was created when i first started to learn. It became a mix of using my Microsoft access knowledge with the use of TO's.


                  For my next project I am going to make sure to design it like mentioned above.

                  • 6. Re: Relationship Design

                    There's nothing wrong with the method that you've used. One of the devcon 2016 sessions that is available now on youtube argues that your method is still good. 


                    Don't think that you have to rebuild from the ground up. You don't have to toss anything away. You can add new table occurrence groups for a specific purpose, such as a report. These could be small groups that are tightly focussed on performing a single job. This way you can get any performance benefits that come from small TO groupings without the pain of rewriting your whole solution. And, getting to these TOGs from your existing solution is as simple as using GoToRelated Record and switching to a layout based on the new TOG ( and vice versa ).

                    2 of 2 people found this helpful
                    • 7. Re: Relationship Design

                      Offhand, do you know if and where non-attendies can obtain the above mention Devcon session?



                      • 8. Re: Relationship Design

                        Steve, you can get 2016 DevCon materials (including links to released videos):



                        • 9. Re: Relationship Design

                          Thank you. I have jury duty next week so this will be great while sitting around.

                          • 10. Re: Relationship Design


                            I have organised my graph a little bit better as you can see


                            As for naming the TO occurrences is there any standards? Also will renaming tables affect script parameters?

                            • 11. Re: Relationship Design
                              Johan Hedman

                              Looks great! Great job setting it up.


                              There are many different ways of naming things, but this is how I prefer things to be


                              CUSTOMER -< customer_PERSON

                                                   -< customer_ORDER   -< customer_order_ORDERROW


                              ORDER -< order_CUSTOMER


                              And so on. Head Table Occurrence in each TOG is Uppercase and then it is uppercase on the sub-table  and each TO in between are lowercase.

                              1 of 1 people found this helpful
                              • 12. Re: Relationship Design

                                Thanks! The graph let itself go a little bit


                                OK I will try this, do you now if changing the name of a table will update the TO that is in an optional script parameter?

                                • 13. Re: Relationship Design
                                  Johan Hedman

                                  All updates that you do to change names in your relationship graph will automatically be updated on all places in your FileMaker database automatically.


                                  There is just a very few things that will not be updates. If you use Evaluate()-function you can have a calculation inside "Case( YOURTABLE::Field = 2; "Do this")" and if you change your Table Occurrence to your_table then Evaluate will not work. But besides that you are good to go

                                  1 of 1 people found this helpful
                                  • 14. Re: Relationship Design

                                    Look at the ddr and see if th TO is named anywhere in explicitly (in quotes). These will not be changed automatically. I.e. If you script parameter explicitly uses a "table name" as a value and not a reference to a field.

                                    1 2 Previous Next