When FileMaker 7 was released a long time ago, developers could finally have several tables in a file. It was a great evolution in our platform history, and we all started designing single file solutions. But didn't we push it a little too far?
There are numerous reasons why designing a custom application with multiple files still make sense. This is NOT another session about separation model.
What's more, FileMaker 16 has brought even more reasons to do so with variable external FileMaker source.
During this session we will discuss the following reasons among others why multiple file architecture makes sense:
- update process: when you upgrade a solution, some data should be updated, some shouldn't. A file dedicated to settings can make sense
- backups: better control the backup process and server performance
- performance (separation model with the interface file on the device)
- synchronisation scenarios
- different access (web publishing, ODBC…)
- server schedules 'load balancing'
- multilingual interface