6 Replies Latest reply on Dec 11, 2013 6:41 AM by philmodjunk

    Design Question

    FilipePimentel

      Title

      Design Question

      Post

           Hello all, 

           I am building a accounting db for 4 different companies - they are all managed by the same accounts team (same Finance Director). 

           I initially created 1 unique db which will hold all the information for all 4 companies, and using scripts I was able to split the info that I require for reports and final balances. 

           But I have been questioning this decision: should I not split this db in 4 smaller ones, and use a splash page where the finance director can then select which company he wants to manage first? 

           Any suggestions are welcomed. 

            

           Filipe

        • 1. Re: Design Question
          philmodjunk

               Let's ask a different question. What possible improvements do you imagine from making that change in your design?

               The "cons" to that choice:

               It's a much more complex design. The more complex your design, the more complex ways exist for how it can fail and the more hours it can take analyzing and fixing problems in the database.

               You'll have to manage layout and many other areas of your design in "quadruplicate". If the users require that you add a new feature, you may find that you have to add it four times now instead of once. (or update 4 different database files by importing data instead of 1.)

               It's less flexible. If there is ever a need to produce a report that combines data from 2 or more of these companies in the same report, It will now be much more difficult to do in most cases. Also, if your business grows and you have to add a 5th company to your system, think what changes you may need to make to accommodate that 5th company.

               A "Pro""

               With a different file or set of files for each company, the design and functions for each company need not be identical. This can allow you to customize your designs to better meet the needs of each company--but keep in mind that now you are really complicating the design of your system when you do that.

          • 2. Re: Design Question
            FilipePimentel

                 PhilModJunk, 

                 That's what I needed. I outside point of view. 

                 Thanks. 

                 Going with only one file! 

            • 3. Re: Design Question
              FentonJones

                   [ I seem to to type kind of slow :-]

                   If the "company" this is for is the "account team" then it seems best to be one database. You'd need a table for the 4 "companies" records, with an ID. Then any movement would go from there to their data. 

                   The main advantage to one database is that you'd only have to make future changes in one place. Otherwise you'd have to do it 4 times; which would be both slower, and annoying.

                   However, this is assuming that the "companies" do not have access to this file. As they would then be possibly able to see the other companies' data; unless you have extreme conditions in place to stop that.

                   On the main "overall" layout table you could have a global field, or a portal showing the "companies." Choosing, or clicking, one could take you to their data. You would need to base most movements and action to continue within that company. So, basically, you'd need to do more to start the one database system, but it would pay off in the future, for changes.

              • 4. Re: Design Question
                philmodjunk

                     Fenton, you may type slow, but your posts are always of value and when I see your name, I read the results with care as there's often something new to learn from it.

                     

                          However, this is assuming that the "companies" do not have access to this file. As they would then be possibly able to see the other companies' data; unless you have extreme conditions in place to stop that.

                     Security is an increased concern with data from multiple companies in the same set of records but...

                     Given the options available in Manage | security, you can set up Record Level Access controls to limit users to just the records that they are authorized to see and it's not too difficult to add in a bit of extra scripted support so that they don't get any records on their layout covered over with a "no access" screen covering a record they aren't authorized to see.

                     See "Editing record access privileges" in FileMaker Help and check out this particular sub section: "Entering a formula for limiting access on a record-by-record basis" for an introduction on how to set this up.

                • 5. Re: Design Question
                  MarkHagood

                       Please pardon the intrusion, I noticed that Fenton Jones had begun an newer to a question back in 2010.  I program a bit in vba with word, but am in need of a brief script for my new endeavor for FileMaker Pro 13.  Time is money so I would gladly offer compensation for a brief script to import a folder of PDF files into a table in a certain way.  If there is any interest on Mr Jones part to go this then I can give exact details.   Thank you in advance, and again accept my apology for being off thread here.

                       Regards,

                       Mark@hagood.com

                  • 6. Re: Design Question
                    philmodjunk

                         If you want to contact some one in the forum, you also have the option of clicking their name and then clicking the link for sending them a private message.