Yes, subtype/supertype. By restricting People to only those fields required for finds and standard list views (9 fields now instead of the 316 prior), Users can search (and download those records from server) from a very fast table in list view or portal. Once they select the person they want, they can view any portion of data (or role) that the person influences within the solution by GTRR (or setting global with that ID). Download from server then would be restricted to only the related records to the single person.
From User perspective, when Dispatch gets a call "hi, this is Charlie Denton" they can type 'charlie den' and find out who that person is, what their various roles may be within the solution, how much they owe or we owe them and so forth. Searching for People seems to be what every business does almost constantly and they will be viewing from iPad.
It sounds like I am trying to convince you; I suppose in a way I am but mostly I am explaining my reasoning for arriving at this perspective. I am tipping this direction more and more since moving to mobile/WAN and losing the inherent speed of LAN. We plan to take advantage of FMSDIFM as well. But narrow tables (few fields) are much faster (since all fields except containers download from server) and 1:1 relationships add no complexity - just typing into field creates and maintains the relationship with Allow Creation ON). BTW, I use modified entity-style and not anchor-buoy so impact is even lower and I can take advantage of the bi-directional flow of data.
Since we are going 1:1 (which I have always used but can now come out of the closet about), what difference does it make where we split up the fields as long as the primary fields they share (in this case name) are in the super type along with those needed for relationships? Oh truly, if I am missing critical aspects then I want to know.
I really appreciate the discussions, guys. These are not easy decisions and this is the base of the solution I am currently building.