By "outside the database" I am assuming you mean that you are linking to tables from another file.
Tables linked via an external data source reference function just as though they were defined within the same table. Once upon a time, links to external files were the only way to related tables due to older versions of FileMaker being limited to one table for each file.
You'll need to investigate your value list definition and the relationship match fields--their values and their data types, to see what is keeping this from working.
The minute I read "investigate your value list definition" it clicked, oh shoot I bet I accidently forgot to select only show related records as of .....
Sure enough that was the problem. Because I've never dealt with pulling data from another file I figured maybe things worked differently and didn't do too much digging.
From a general stand point, what are the performance/design advantages and disadvantages to have things sit in different files versus all under one roof?
There are trade offs for either approach. Multiple files complicate your solution and we often recommend that new developers keep it to a single file for that reason. Controlling access via a password is more complicated as you define accounts and passwords in each file. This usually requires defining identical account names and passwords in each file for each user--managing them becomes something best done with global fields and scripts.
Since variables only "live" in a given file, other means to move data from one table to another must be set up and you may no longer have a single central Relationship graph documenting all your relationships.
On the other hand, deploying updated copies of your solution are much simpler with individual files as you may only need to swap out a single file for a new one and then only import that file's data into the new copy.
Many developers use a compromise design approach called the Convert to Seperation Model. It splits a solution into two files: Interface and Data. The Interface file contains all scripts, layouts, value lists, etc and the Data file contains all the data tables. This approach allows you to deploy new copies of the interface file simply by replacing the old file with the new.
Very cool, never thought of that. This would allow me to test changes until my face turns blue and not disrupt the live database. Thank you very much Phil :)