Thank you for your post.
If there is no reason to put the information into separate tables, then don't! It is much easier for FileMaker to read information from the current table then to perform a lookup across the other tables for information. If some information is not necessary to be displayed on a particular layout, then omit it, and put it in another layout.
However, if you have three or four phone fields, or several container fields, you may want to consider putting that information in a separate table. That way, one user may have one phone number, while another has four or five phone numbers, or one user may not have anything in a Container field while another has ten images.
In other words, if you have redundant data, put that into a separate table and reference it.
This would also be a good time to mention something from Jon Thatcher's under the hood session at DevCon. One2One relationship are beneficial when it comes to large data in fields that are rarely used. When in a served enviroment, FileMaker will download all the data from EACH non-container field of the entire table even if it only on field is referenced on the layout, tab panel, or portal.
Therefore, if you have large blocks of information such as a log field, this should be in its own table, even if you want to keep it in one field for some reason, and should be using form view.
Actually there usually is a good reason to split data into seperate tables when the relationship to the superordinate table is identicle. Typically its an issue of decentralization of the data for any of dozens of reasons.
Assuming the data are alphanumeric I can see why one would want it all in one table from a performance standpoint. It does go faster... alot faster... Unfortunately in the case of the above the app that intiated the question is using graphics in a container...:smileysad:
It's my experience there's not much one can do to speed up an app which uses containers to show lots of graphics.