2 Replies Latest reply on Jan 7, 2013 6:58 AM by GordonShewach

    Multiple Tables in 1 file vs. Individual Tables


      Coming back to FileMaker from V4.1 and have a basic question. What are the advantages to combining tables in a single file? I am guessing it makes the standalone apps work (better). I wonder if there are drawbacks to having multiple tables in a single file. Back in the day all I could do was relate flat files and that will still work for some of the things I would like to do now. If there are other advantages to combining multiple tables in a single file then I would start working that way rather than the old faithful way. Sorry if this is such a low level question and if there are resources that you could point me at I would appreciate the tip.

        • 1. Re: Multiple Tables in 1 file vs. Individual Tables

          It all depends on how complex and big (data-wise) your solution is.  The rule-of-thumb is to keep tables with relatively static data in a separate file (helps with backup speeds given FMS12 hard linking backup feature).  It also helps speed up the new FMS12 progressive backups.


          Keeping all tables in one file also increases the risk of losing everything is the file ever gets corrupted due to deployment issues.

          • 2. Re: Multiple Tables in 1 file vs. Individual Tables

            The advantages of multiple tables in 1 file are extensive:


            • It eliminates redundancy with common elements that otherwise would have to be created in all databases and updated in all databases such as value lists, navigation scripts, and other common scripts.


            • Scripting is easier, issues regarding global fields and global variables are easier.


            • I do most of my testing by building code in the "live" database with the first step being a Halt Script so no one can accidentally deploy it, then making a copy of the database and disabling the Halt Script. With multiple databases you'd have to go through multiple steps to rename the databases or separate the databases from the live to make sure you're working in the copies.


            • Maintaining a single relationship graph, Security managed in a single place, one set of Custom Functions, one set of Custom menus.


            Many other reasons that I believe have been delineated in other forum threads.


            Wim is right that you have to be concerned about a database going bad, but you can eliminate this concern with robust backup strategies. He's also right about having a large amount of static data slowing down backups. But with external storage in .fmp12 and fast hard drives, you can eliminate this concern.


            The most compelling reason I've heard for multiple databases is building a vertical market solution where you need to send updates out to your customers from time to time. Because I don't sell these, I just directly update any of my clients systems, as needed.


            I have a few legacy systems that got upgraded from .fp5 and that I did not merge into a single database (limited resources for the client). Every time I work in them I'm reminded of how much easier it is to work in a multi-table, single file database.


            Gordon Shewach

            Desktop Services

            Ann Arbor, MI