The two biggest limitations to run times are that they don't access/share/host files over a network (Can't be the client, can't be the host) and you can't use save as PDF as the adobe technology wasn't licensed by FileMaker for that use. (You can "Print" to a PDF printer, however.)
When you use the developer tools to generate a runtime system, it makes a copy of all your solution files that you have selected for the run time, then adds a "crippled" copy of the FileMaker application plus all needed support files to a folder. Your users can just copy this folder to their computer and use it or you can use an installer to set things up for them in slightly more user friendly fashion. The biggest detail that complicates this process is that you need advanced installed on a Windows system in order to generate windows runtimes and then a copy should also be installed on a Mac system in order to generate Mac runtimes.
The advantages and trade offs to using one file for each table are pretty much the same as for regular Filemaker. You can select a whole list of files and "bind" them into a runtime solution so having extra files is not, in itself, a problem for your run time solution. You may want to consider using the "data separation" model instead of individual files for every table. In the data-separation model, you use two files, one for the data tables and one for the user interface. Manage | Database | Relationships in the interface file uses external data source references to link to the tables in the data file. With this option, you can send out new interface files with all the layouts and scripts to your users without their having to import any data--they can just swap out the old inteface file for the new.