8 Replies Latest reply on Jun 9, 2012 12:30 AM by jbrown

    Solutions are complex, right?

    jbrown

      I'm rebuilding a database that I created when I knew nothing about Filemaker and developing databases. Since, 3 years later, I'm a few steps away from that know-nothing state, I see some messes that I made in the previous version.

       

      But I'm still troubled by the fact that my reelationship graph is well-populated with instances of tables. I keep thinking I'm taking an inefficient method by creating relationships that help me filter out the data. But my thinking is incorrect, right?

       

      Systems get complex. The more functionality, the more ways you have to look at data, whether displaying it in a portal or a graph, you need multiple instances of a table. Right now all my students' grades are in one table with five fields: student ID, grade, class, school year, and subject. I need to display the data in different ways: By year, by subject, etc. And one of those ways is to use a relationship.

       

      I saw a recent post about someone creating a different TO for each global field to allow choices for the user, with the 2nd, and 3rd and so on field narrowing the choices based on the previous choice.That requires multiple TOs. That's just how it works. right? Sometimes you have multiple TOs, to accomplish what you need.

       

      Solutions get complex, right?

       

      Can anyone show me what your relationship graph looks like? (not sure if that's highly-protected stuff or not). I'd like to just confirm that as the systme gets complex, the relationship graph grows and grows and grows.

       

      I am coming into a fairly deep understanding of the power of the relationships piece of a solution. I am sure there's more to learn.

       

      ^ just my random thoughts.

       

      jb

        • 1. Re: Solutions are complex, right?

          Hi Jeremy,

           

          There are many different ways of building the RG. Ray Cologon has them catalouged in his white paper which is, in my opinion, required reading if you want to discuss the pros and cons of any style.

           

          It is in the Technical Briefs and White Papers section with the title "Approaches to Graph Modeling"

           

          You'll likely want to pore over his paper both before and after you hear his presention to next month's DevCon!

           

          Cheers,

           

          John

          • 2. Re: Solutions are complex, right?
            taylorsharpe

            Oh yes, things get very complicated.  In the past if we even had one place where we needed to set the context to another table, we had to add it to the relationship graph.  What is nice in version 12 is if you only need it once and it can be displayed by a SQL call, you can do that with the Execute SQL instruction and this may minimize the amount of table occurrences we need since SQL steps can set their own context independent of the layout.  Here is the current database I am working on, but as a developer, I work on lots of different databases. 

             

            Untitled-1.jpg

            • 3. Re: Solutions are complex, right?
              PalmDBS

              Yes, things can get complicated. While the RG may look cluttered, it's important that a developer be able to make sense of it when working on future modifications.  Sometimes there may be an existing relationship that gets what you want, but it's more important to maintain the perspective/context of where you are in the system.

               

              Here's one of our products that was highly modified. Low res to protect client. 

               

              RG.jpg

              • 4. Re: Solutions are complex, right?
                erolst

                - Taylor

                 

                And I thought my Relationship Graphs are a mess; thanks, you made my day!

                 

                - Jeremy:

                 

                I had some deeply philosophical thoughts about the RG I wanted to share, but Ray Cologon can't be beat!

                 

                Does someone know why he hasn't written an FM 11 Bible?

                 

                PS: Here's another one:

                • 5. Re: Solutions are complex, right?
                  taylorsharpe

                  Take a look at dbmike's graph... it looks like he is using Anchor Buoy system which is a good way optimize FileMaker so that any given layout is only thinking about what it has to and not thinking about a bunch of unused table occurrences.  It has some disadvantages too, but if you need to improve performance, it sure can help. 

                  • 6. Re: Solutions are complex, right?
                    PalmDBS

                    Yes, we use anchor buoy. This particular implementation strayed a little bit (another developer had joined anchors). I'm relatively new to FileMaker and it took me a little while to appreciate the benefits of anchor buoy. Working in a development shop with multiple programmers, it is far easier to understand the intent of another developer in anchor buoy, as well as far easier to modify a particular relationship without damaging other aspects of the solution, especially with a modular setup. Even though we use anchor buoy, I need to read Ray's white paper to learn some.

                     

                    I really wish I knew about FileMaker years ago!

                    • 7. Re: Solutions are complex, right?
                      RonSmithMD

                      Very messy sometimes. PaperCutPro, my paperless medical records/practice management solution started in 2000 to simply record vaccines and generate the required school vaccine records that my office had to supply to parents. Now it does everything, and I mean everything! (http://www.papercutpro.com) So it is very complex. I had to reduce my graph from 2500+ wide X 1400+ tall to 450 wide.

                       

                      Ron

                       

                      PaperCutPro, a complete paperless medical records solution

                      83 tables with 1 primary database and 3 accessory databases

                      624 relationship

                      361 layouts

                      1242 scripts

                      111 accounts

                      60 custom functions

                      104 custom menus

                      Clones total 33+megs

                       

                      PaperCutProRelationships.jpg

                       

                       

                       

                       

                       

                       

                      • 8. Re: Solutions are complex, right?
                        jbrown

                        Thanks all. (I was at Prometheus. It was pretty good!) 

                        Thanks for the shots of your graphs. It makes me feel okay that my RG is gettin a bit complicated.