Being new to v11 having last used v4 wasn't sure whether the file ends up being extremely large due to all data being stored in the one file with many many tables?
It's possible, sure. You can strategize on how many files you use, and what tables to put where, if you like.
Of course the file size limits are greatly increased in newer versions of FileMaker. For most uses, it's a non-issue.
to some extent data is data, one file with five tables is similar to five files each with one table, once there is enough data to get beyond the initial file only overhead.
A quick test of a file ( a RandomStringGenerator) with 2 fields and 31000 records, export as 3 different files ( to avoid the bit of scripting etc. in the source)
A field 1 - 434 KB
B field 2 - 860 KB
C field 1 and field 2 - 1 MB
a second test on 100,000 records
A 1.3 MB
B 2.7 MB
C 3.2 MB
which suggests there is some size efficiency in multiple tables in one file
One thing that shold be considered, it putting all container fields in a separate data file of their own. This keeps the primary data file relatively small, and often emailable when necessary.
A new empty file is 53 KB
As others have said, size is pretty much a non-issue unless you're getting into Terabytes of data.
The choice, however, between multiple files vs. single file/multiple tables I think is an easy one. The efficiency of the latter is amazing. For example, I have a FileMaker 6 suite of databases that inclues 64 separate databases. There are many common elements in these databases: accounts, privilege sets, utility scripts, navigation scripts, value lists, etc. In FileMaker 6, a change to any of these common elements requires a change in 64 databases. This same 64-database suite, however, is now a single file/64-table database in FMP 11. A change to any of these common elements is now done just once. There are other efficiencies as well including: scripting cross-table, relationship graph, custom functions, custom menus, and others.
Unless you have reason to do what's called the "separation model" which is helpful if you're dealing with a vertical market solution and need to send out regular updates, I'd recommend a single file/multi-table database.
Ann Arbor, MI
I second Gordon's comments about simplifying the solution with a single file (or dual file for separation models) for one basic reason:
I needed about 20% as many total scripts and layouts to build a single file solution rather than a table-per-file solution with a dozen+ tables. Scripts can be reused if carefully purposed with variables from their buttons or contexts, and layouts are centralized without requiring any redundancy among files to have layouts for each base-table.
Years ago, when 7 was first released, I was in the middle of a major project which was growing in file count as new-table requests from the client increased. I moved the entire thing into one file 2 months before the deadline (4 months into development!), scrapping unnecessary scripts and layouts, incorporating tabs to reduce layout count, and delivered it ahead of schedule!
The introduction of Script Folders has made organizing them by base-table or other common factors much simpler as well in newer version.
I go out of my way to avoid adding files to solutions now.
Retrieving data ...