7 Replies Latest reply on Dec 12, 2012 9:18 AM by Order_from_Chaos

    Separation Model Question


      I know this has been discussed elsewhere but I am curious about others experience with the separation model. I've used it for some relatively moderate sized projects (thousands of records, 20 - 25 tables, 3 or 4 files). It certainly has appeal for FileMaker Go and WAN access. I've read where some have advocated an absolute minimum be in the data file other than the base tables. Value Lists and everything else should be defined in the UI file. My question is:

      With value lists unavailable and no relationship information in the data file, how do you enforce validation other than through robust scripting?

      Do you banish most calculations to script generated data that places values in generic Number and Text fields?

      With the above, I can see significant performance enhancement (especially with very large tables) but also danger of not having current data unless things are VERY carefully scripted.


      What is the recommendation from those of you more seasoned at this? I really want to put things together in an extensible and robust way.





        • 1. Re: Separation Model Question

          Hello, Brett.


          From the way your question is phrased, I'm going to assume you're talking about a separation model where the interface file(s) live on the client computer and the data file(s) live on the server. (If that's not right, please let me know.) But I think we need to clear up a bit of a misconception about the model.


          You're under the impression that the data file needs to have no value lists or relationships in it. My question would be, why? There at least a few reasons why this might not be true:


          1) Under Server 12, value lists are built on the server, then loaded to the client on demand. This was done on purpose as a performance enhancement (if you don't have to shove all the records over the wire to build the lists, you save a bunch of bandwidth). So putting value lists on the server actually speeds them up.


          2) Relationships on the server side should be built, to the degree needed by the data file - to include calculations (auto-enter or otherwise), value lists, etc. Calculations will process much faster under Server, which doesn't have to contend with the bandwidth (and which is fully 64-bit now). You don't have to build them all (in fact, probably shouldn't); just build the ones you need.


          3) Once you have the structure in place in the data file, you don't have to build a bunch of scripting to do what the schema should be doing for you. That's a big plus.


          Hope that helps.



          • 2. Re: Separation Model Question



            Thanks for the quick reply and the detailed information on how FMS handles things. I should have mentioned at the outset that I am hosting on FMSA on a Mac Mini running Mac OS X 10.8.2 Server. I mostly run client software on Macintosh as well but use the iPhone and iPad as well. I've seen a lot of different recommendations on how to implement the separation model. It seemed to me with some recommending no schema that you lost a lot of the power and flexibility that FileMaker offers. The validation options were a particular concern for me since scripted validation would not be as reliable.


            Any other pearls? My latest project will likely have in the 100K's records so looking for options that scale well.



            • 3. Re: Separation Model Question

              Brett -


              One general idea to consider when you're working on mobile devices is to restrict the data you load to the device. Don't try to shove all the records down to the iOS gadget; you'll suffer performance hits (especially over the cell network) that may just make the app unworkable. Instead, think in terms of two completely separate environments - desktop and mobile - and plan the app for those environments.


              Most mobile applications don't try to store 100s of thousands of records. They're usually JIT (just in time) sort of affairs, holding just the stuff the user would be interested in, right now. So figure out what the user needs and load just that to the mobile device. Maybe it's just that user's records that are active, maybe it's just the records that need attention that day, whatever the business rules need. But leave the rest in the main database for reference later.


              This can be made easier in a separated environment because all you have to load is the key fields into a set of parallel tables that use 1-to-1 relationships back to the data file on the server. The tables on the mobile device are completely volatile; the records can be blown away and recreated at will. Can't get a much easier sync process than that.   


              Just some thoughts.



              • 4. Re: Separation Model Question

                I've seen a lot of different recommendations on how to implement the separation model. It seemed to me with some recommending no schema that you lost a lot of the power and flexibility that FileMaker offers.


                As a guideline, you should express relationships between tables in the UI file not in the data file.


                The separation model is using different files for the data and the UI. The relationship graph for these files does not need to be the same. Your concerns relate to the validation of data. You may want to construct relationships between tables in the data files for data validation.  However, the UI file is used to visualise data. The data file does not need to express those relationships.



                • 5. Re: Separation Model Question

                  Thanks Malcolm.


                  The small projects I've tried so far have used the approach you mention. I had seen other recommendations to try to have the data file as spare as possible and was trying to wrap my head around how that would work.



                  • 6. Re: Separation Model Question

                    You said it! Some relationships, some value lists, some calculations, some scripting (perhaps) and some 'whatever' may be necessary in the data file(s). But MOST of the work is done in the interface file(s).


                    Think in terms of web interface. If you have a database driven website, the HTML/JavaScript/CSS/PHP (or other web application) do the work and is the interface. The database merely stores the data. That's the separation method/model!


                    You need to decide how much separation you'd like within FileMaker as interface and data. Hopefully you've gotten enough from these replies.


                    -- sent from my iPhone4 --

                    Beverly Voth


                    • 7. Re: Separation Model Question

                      I really appreciate the comments. One of the strengths and pitfalls of FileMaker is its flexibility. Its good to experiment with different approaches. Thanks again for the feedback!