All the options you mention can be made to work. Each option has different trade-offs. Which is "best" depends on the complexity of your system and how you will manage any update releases to fix problems with the system.
Well i was thinking using seperate files to
hold the data to keep the main file
size down since they will be pre loaded with lost of data... The modules files should not be allowed to be open itself, only to have the data pulled into the main file. Then when i need to
make a update like adding extra fields they can download the new module file and replace the existing... Ive never used external tables/fields from
seperate files before so im a bit worried it may be a something im over my head with.
The main file will have seperate layouts and my navigation script will send the user to different variations of the same layout based on a calculation that evaluates which module the user has active.
Would you recommend this approach?
Splitting up your solution into one table per file simplifies certain upgrade and/or update processes as you can limit all the changes to a single file, but you pay a price for that simplicity with increased complexity in other aspects of your design.
Any accounts and passwords that control access to your file now have to be installed with identical account names and passwords in each file. This can be managed with a script and you may be able to simplify the process a bit by using the re-log in script or the file options setting to auto-enter specific passwords, but no matter how you approach it, you are looking at greater complexity in managing your access control settings. And a script set to run "with full access control" only has full access to data in the same file, it can't access data in an external file with full access. There are work arounds that solve the issue for this as well.
Relationships become more complex in some ways. Calculation fields that access data in other tables require that relationship in the data file where the field is defined. Scripts that use a relationship to access data must have that relationship in place in the same file where the script is defined. The same is true for layout elements that refer to related data. So this means that you end up with multiple relationship graphs to work with and maintain. That isn't all bad, however. It can result in relationship graphs that are simpler as they separate out the data level relationships from the interface level relationships.
There was a reason, after all why so many of us that have used FileMaker for many years were repeatedly requesting the ability to put multiple tables in the same file....
When you work out exactly how you want to go forward, consider these alternate approaches as well:
Data imports can be scripted so that all the user does is click a button, select the original file in a dialog and then everything else happens automatically, the data is imported and serial number fields have their next serial values updated at the same time.
Some developers use the Data separation model. Instead of one file for every table, they set up two files, one for all the tables and one for all the layouts, scripts etc.
Enhanced value features can be present in the file, but hidden and disabled for the user that has not purchased the authorization to use them. With this approach, a user can upgrade and get a new key that unlocks the additional features and they don't have to replace any files or import any data. This also means you can manage all the different variations of your solution without needing a different file for each option and that can really simplify things for you as the developer. I don't know this for a fact, but I suspect that FileMaker Inc. uses this method with FileMaker Pro vs FileMaker Advanced and for FileMaker Server vs. FileMaker Server Advanced.
Thank you very much Phil! This was a very helpful read :) i will be getting started on things over the next week or so. I think i will avoid the multiple files route and try and keep everything together with the extra features hidden from the ones that have no paid for them.