7 Replies Latest reply on Sep 29, 2011 12:32 AM by KDF

    Tables vs Files (with tables)

    CountryBoy1

      Title

      Tables vs Files (with tables)

      Post

      I previously used Filemaker Pro 6.  Filemaker Pro 9 is much different in that a file can have

      many tables.  In designing a new database that is "stand-alone", that is, none of the tables

      are referenced by any other external database, should the tables for the new database all be in

      just one file ?  What are the pros and cons ?

       

       

       

        • 1. Re: Tables vs Files (with tables)
          davidhead
             I think that is a hard question to answer. It would really have to be answered for each database solution. However, if I was to make a choice, I would say put all the tables in one file until you find a compelling reason to put one into another file. That may seem trite but simple is best. Having all the tables in one file does simplify a lot of issues including security. But there are reasons to have tables in separate files. When you find these reasons, do it!
          • 2. Re: Tables vs Files (with tables)
            jda76
              

            I was reading this thread and would like a little more info...

             

            When we converted to 8.5 from 6 we began condensing our files, adding them as tables in other files, i.e. invoiceitems became a table in invoices, etc., but we weren't sure where to draw the line.  Besides security issues we couldn't really see a strong reason to pull us to one side of the fence other than the time involved.

             

            You mention there are reasons to have tables in separate files, could you name a few?  We haven't come across any yet. Currently we are conflicted between wanting to condense our files into tables because it seems cooler :) and leaving well enough alone since it's working as it is.

             

            Any further insight would be awsome.

            Thanks!

            • 3. Re: Tables vs Files (with tables)
              Sorbsbuster
                

              There's probably a Forum Rule against people jumping on a band-wagon and asking follow-up questions, especially when the original post is marked 'Solved!.  But I have a query like jsmarvey's:

               

              In the good old days when all 'Tables' were separate, but related, files, we could issue out the suite of files for the users to work with while we beavered away developing bigger and better features in the background, starting with a clone of the file the users were currently working with, with some out-of-date data.

               

              Then when we wanted to release the next version of the 'Stock File', for example, we opened the current Stock File, imported all its records into the new (updated), empty file, and released it.

               

              But if we do the same thing in a scenario where the Stock File is actually the Stock Table, and is part of a single file that also contains, for example, the Product Table, the Purchase Order Table, the Invoices Table, etc, then do we not have to import all of the current records into all of the tables in the updated file - even though it was, say, only features in the Stock Table that had been updated?

               

              It's one of those cases where I think I'm going to be red-faced when someone shows me how much time I've been wasting updating all the Tables in a solution when I know that only one Table, say, was updated...

               

              Thanks for your help,

              Alan

              (Or, on further thought, is someone going to tell me that I can open the working file, then open the updated file, and replace the complete Stock Table in the 'old' file with the new 'Stock Table'?)

              • 4. Re: Tables vs Files (with tables)
                davidhead
                  

                jsmarvey wrote:

                 

                You mention there are reasons to have tables in separate files, could you name a few?  We haven't come across any yet. Currently we are conflicted between wanting to condense our files into tables because it seems cooler :) and leaving well enough alone since it's working as it is.

                 


                There is a good rule here for systems that have been upgraded from FileMaker Pro 6 - if it is not broken, don't fix it. Although there are workarounds for these reasons, here are some things that may make you put tables into separate files:
                1. tables with (relatively) static data that do not need to be backed up all the time
                2. tables with a lot of data (e.g. large images) that should be backed up separately
                3. sets of tables that create separate modules that may have different access privilege sets
                4. creating separate user interface and data files in "the separation model"
                5. tables with reference data that can be swapped out quickly and regularly
                There are a few for you to ponder. Comments welcome. 

                 


                • 5. Re: Tables vs Files (with tables)
                  farosa
                    

                  I have a related question:

                   

                  Once I have designed a system with one file and many tables how can I change it to the old way of separate files.

                  In other words is it possible to change a table into a file without doing all the work from sratch ??

                  • 6. Re: Tables vs Files (with tables)
                    mrvodka
                       You can always import the table into a new file or make a clone of the file and delete out all the tables you dont want for the new file.
                    • 7. Re: Tables vs Files (with tables)
                      KDF

                      Is there  a way to easily convert multiple separate files into a single file with many tables?