2 Replies Latest reply on Aug 30, 2013 10:16 AM by philmodjunk

    A little advice on tables or files?

    jackmac

      Title

      A little advice on tables or files?

      Post

           Quick question.. traditionally I've built a new table for each element of what I'm doing. I've had a client ask me to build a system for them and I've been looking at alternative routes.

           He currently has three indivual Access files - one for Customer details, one for Support Details and the other for Products. They've asked me to create a central system which makes sense.

           I could create one file with three tables in it or I could create three files and then one 'central' file which pulls the data together.

           If one of the files ever corrupted, the system won't fall over, same can't be said of the tables route.

           Anyone any suggestions on the pros and cons?

           TIA

           Jackmac

        • 1. Re: A little advice on tables or files?
          davidanders

          https://www.google.com/search?q=tables+vs+files+filemaker

               LINK #6     FileMaker Design: Single database with many tables vs. many databases
          http://www.davedowling.com/content/filemaker-design-single-database-many-tables-vs-many-databases

               LINK #7   advantages of consolidating multiple files into one
          http://gnurps.com/filemaker/one_file_vs_many.html

          • 2. Re: A little advice on tables or files?
            philmodjunk

                 If one of the files ever corrupted, the system won't fall over, same can't be said of the tables route.

                 File corruption is file corruption. If one of the files are corrupted, you have a problem that has to be resolved whether your system consists of 1 file or four. Recover can almost always repair your file to the point that you can import the data from it into a clean, uncorrupted backup copy.

                 Using multiple files with a file in each plus an interface file will complicate the design your solution--especically when it comes to managing accounts and passwords to control access to your database as you have to set up accounts in each file. Calculation Fields that combine data from two more related tables will also complicate your design as you end up with four relationship maps instead of 1 to manage and maintain.

                 That doesn't make doing it that way a bad idea, but you do need to "count the cost" to see if the benefits merit the extra trouble you have to go to.

                 A possible compromise is to use two files instead of four. This puts all your data in one file and all your scripts, layouts, value lists, etc in the other. This is called the Convert to Seperation Model and it allows you to deploy updated interface files without having to import any data as you just swap out the old interface file for the new and this can reduce the amount of data imports you might need to do when deploying a new version of your database.