I would build one API file where I ask for different data instead of having separate files. I would also try to have as small solutions as possible and keep them in one file. Always hard to keep different files up to date and handling local files from many users
My question is would it be more efficient if I keep a single script GetValues in Main file and then call this script from the files A, B and C with different parameters. Or is the effieciency the same with the scripts in each file.
It may not work if the script needs to interact with data (loop through and read from records). Having the script in the main file would not give you access to the data in files A, B and C unless you add Table Occurrences of those files into the main file. Which comes very close to the Data Separation Model.
It is easy to copy and paste scripts between files, I keep a library of the scripts I use the most in FMbutler's Clip Manager.
If files A, B and C share many things in common you have to consider whether they really need to be separate files...
Thanks for the reply..
Yes, no that the files are getting more complex, I am having trouble keeping the different files updated.
All three files A, B and C share most of the ESS tables and also have a few of individual FM tables.
My concern is if I move all three files to the Main file, would the database get more complex and hard to manage and also would it affect the performance.
How do I build and maintain an API file for Filemaker. Unfortunately my Main file would get very big if i merge all the files together and I am not sure how that will affect performance again.
Also sometime in the near future I will have develop an offline version of all these files and sync them when the user gets online. So I really want to do this is in the most efficient way possible to keep things running as smoothly as they can get.
Any guidance and advice would be hugely appreciated.
it sounds like there is some redundance in all 3 files - so moving it into one might improve performance if well designed ...
yeah.. I was thinking of ways to do it in a well designed manner.
Also I just became aware of the Data Separation Model.
Is DS Model suitable for bigger solutions.
Most of the tables in my files are ESS tables and I am using stored Procedures to make changes to these ESS tables instead of using scripts to do it.
If that's my approach, would DS Model be of any use at all.
Or can I just keep them all in one file and not worry about DS Model at all.
I am still figuring out what the best approach to this will be. My project is only going to get bigger and more complex in the future.
the DS Model has many advantages but introduces new redundancy - some stuff has to be maintained in all files involved - like security management etc. - also parts of the graph have to be for the interface file as well as for the data file depending on your logic / relational dependency requirements ..