Multi-file solutions in FileMaker
Everything in a single file or better use multiple files?
What do you prefer in FileMaker development? Do you want to implement everything in one file or are you developing a multi-file solution? Both development approaches have their advantages and disadvantages. In this article, the strengths and weaknesses are explored a bit. Both concepts can be implemented with FileMaker.
FileMaker history
The first versions of FileMaker could only work with one table per file. Somewhat later, it was possible to link several such files and come up with multi-file solutions. There was still a single table in each file, but they could be linked. Solutions from that time (early 90s) often were built with many files, corresponding to the number of tables you needed.
Starting with FileMaker Pro 7, you could combine multiple tables into a single file. Building relational databases became much easier. In version 12, a new data format was introduced and the possible sizes of tables and files were significantly increased. Suddenly FileMaker was also suitable for large amounts of data. From this time FileMaker solutions returned to the single-file-approach because complex applications could be mapped within a single file.
Today you can create solutions with a single file as well as with multiple files. Furthermore, external data sources can be integrated quite easily. From all these possibilities, FileMaker solutions can look very different today:
- Single-file solution
- Multi-file solution
- FileMaker as user interface with external data sources
- Any hybrid.
FileMaker peculiarities
A separation of user interface and data structure, for example, is taken for granted in many development environments. This is not the case in FileMaker. Each layout, for example, must have a table associated with it. A strict separation of database and user interface is therefore not possible.
However, approaches to separation can very well be implemented. For example, you can use a neutral table for some tasks. If you like it a bit more advanced, you can map all records to the layout of a session table, while the other data remains in the background, so to speak.
FileMaker can also be used as a frontend for external systems. There are several ways to integrate external databases. The development of a user interface is particularly fast and easy in FileMaker. External tables are displayed via the relationships graph and can then be used as easily as internal tables.
There are several ways to separate data. What are the advantages or disadvantages when using these models?
Single file
Advantages
- Simple file handling
- All-in-One
- Easy deployment to mobile devices
Disadvantages
- Possibly unsuitable for large amounts of data
- Possibly unsuitable as document management
- Updates are costly
Multiple files
Advantages
- Separation of user interface and data on request
- Large amounts of data can be managed in separate files
- Large files can be addressed only when needed.
Disadvantages
- Data maintenance and backups are more extensive
- Access rights must be regulated across different files
- Planning is more complex.
Application examples
It is safe to assume that a single file solution is a modern standard for FileMaker development. It is no problem to manage even larger amounts of data in a single file. That is the starting point.
There are these two main reasons for a multi-file solution:
- Separation of user interface and data
- Outsourcing of particularly large amounts of data.
Separation of user interface and data
You can designate one file as the “user interface” and outsource all customer data to other files. Regardless of the amount of data, such a solution can offer certain advantages. If, for example, all logic and functions are stored in the user interface file, updates and upgrades can be implemented particularly easily: You only change the user interface file, while the customer data remains untouched.
Many FileMaker developers develop in the style of “open-heart-surgeries” when they intervene directly on the customer server in files that are used live. FileMaker allows this, but wouldn’t it be much safer to work on a copy of the data? The alternative here would be to designate a file as the user interface and use a copy of that file to develop new features and bug fixes. Once everything is tested, only the user interface file needs to be changed.
In this last variant, it does not matter whether the copy of the file is developed on the server or locally with a copy. If you edit the data offline, it is recommended that you also use the data itself (the other files) as a copy and possibly only with sample data, offline. You build a shadow system for the developer, so to speak. When all the adjustments are done, the file can be replaced very quickly with the user interface.
Outsourcing of particularly large amounts of data
Another reason to rely on multiple files is the amount of data. Different scenarios can be thought of:
- A document repository benefits from external files that hold the documents. Think of images, PDF files and other file formats managed through FileMaker.
- Manage specific data in standalone files. This can increase the clarity for the developer.
- External files for data storage allow to create files per year, per customer or per client.
FM Starter and FrankCRM
The two products “FM Starter” and “FrankCRM” are offered as a one-file solution. Deliberately chosen for the simplest structure. Of course, it doesn’t have to stay that way. The developer is free to create a multi-file solution from these files if that serves the project. Possible reasons for this were listed here above.