1 of 1 people found this helpful
In its simplest form there is one UI file and one Data file. But whether that makes sense depends on your solution and the impact on things like backups. You can certainly have multiple UI files and multiple Data files. If you tables with static data (data that does not change during the day) then it makes sense to split those tables off into a separate Data file. That will help a lot with backup speed and the disk space it consumes.
1 of 1 people found this helpful
Adding to Wim's comments, I would say that there are several considerations:
1) Are these different clients all nearby, geographically? It may make sense to split them into different instances if they're separated by a significant distance, since latency is at least loosely related to the distance between the client and the server. Latency is probably enemy #1 when it comes to performance.
2) If you split the data files by client, then you can control the security on those files more easily than you can by combining them. On the other hand, the more files you have, the more places you have to update. (Naturally, if you use a different UI file for each client, then access can be greatly simplified - but it also means more places to update.)
3) I would definitely not go with "one table per file". There's no good reason to do that, and you create a real headache for yourself from a maintenance standpoint.
4) If you have any container fields and plan to use externally managed containers, I would definitely split those out into a separate file. Not only is backup easier, migration of container data is a real pain. Minimizing it is a Good Thing.
5) Remember that the separation model is not a panacea. While it can often make your life easier when doing simple updates, many times, an update will require a schema change in the data file, so you wind up having to update both files (interface and data) anyway.
6) You don't mention what kind of hosting you're planning on using, but if you're thinking about a commercial hosting company, be aware that many of them charge based on the number of files you have. It's probably not a big difference, but it's something to think about. (And don't forget the 125-file limit on each FileMaker Server instance.)
7) If the solution does or ever will utilize a synchronization protocol, be aware that this can be greatly complicated by having multiple data files.
Just some considerations. HTH
Hi Wim and Mike,
Thank you a lot for good answers. When I talk about clients I mean different companies that will run their own database. In this case different companies that grow plants in greenhouses and that needs to keep track on the chemicals that they use (the authorities monitors them now and then). So the maintenance consists of me making newer "versions" of the data base product, but also when FM upgrades the whole product.
The distance between the clients and myself, could be a days travel, maybe more if I am lucky and start exporting.
Deployment could be a FM Server for the larger clients, each client having their own server. I think that would be the simplest, but hosting might be an option, that I have not thought about. But there will also be small clients that will run the whole thing on one iPad.
From what you write, I think that I will split it something like this:
a) UI file
b) datafile with data that almost never will change, such as client specific data that is entered during setup of the system and such,
c) datafile where the day to day data is entered and manipulated, in this case each time that they use a chemical and what it is used for etc.,
c) a container file
Thank's again for great input!