It all depends on how complex and big (data-wise) your solution is. The rule-of-thumb is to keep tables with relatively static data in a separate file (helps with backup speeds given FMS12 hard linking backup feature). It also helps speed up the new FMS12 progressive backups.
Keeping all tables in one file also increases the risk of losing everything is the file ever gets corrupted due to deployment issues.
The advantages of multiple tables in 1 file are extensive:
• It eliminates redundancy with common elements that otherwise would have to be created in all databases and updated in all databases such as value lists, navigation scripts, and other common scripts.
• Scripting is easier, issues regarding global fields and global variables are easier.
• I do most of my testing by building code in the "live" database with the first step being a Halt Script so no one can accidentally deploy it, then making a copy of the database and disabling the Halt Script. With multiple databases you'd have to go through multiple steps to rename the databases or separate the databases from the live to make sure you're working in the copies.
• Maintaining a single relationship graph, Security managed in a single place, one set of Custom Functions, one set of Custom menus.
Many other reasons that I believe have been delineated in other forum threads.
Wim is right that you have to be concerned about a database going bad, but you can eliminate this concern with robust backup strategies. He's also right about having a large amount of static data slowing down backups. But with external storage in .fmp12 and fast hard drives, you can eliminate this concern.
The most compelling reason I've heard for multiple databases is building a vertical market solution where you need to send updates out to your customers from time to time. Because I don't sell these, I just directly update any of my clients systems, as needed.
I have a few legacy systems that got upgraded from .fp5 and that I did not merge into a single database (limited resources for the client). Every time I work in them I'm reminded of how much easier it is to work in a multi-table, single file database.
Ann Arbor, MI