in reply to modeling relationships

It would help in both Programming, and database schema, if you abstract the problem, and think in terms of objects, relationships, properties and KEY fields.

In your case, the primary object is "Person" with a person-ID as a Key field.

The person(object) has a Property - "place".

The person has what appears at first sight, to be 2 "relationships" - whach can be named "assistant" (Can there be more than one ?), and "Boss/Works-for" - again - can there be more than one ?

If you think about it, these relationships define the same thing, and you can avoid a multitude of data integrety and programming erros by using a single relationship for this - I would suggest a "boss" relationship, which is usually a one-to-one. This allows a "boss" to have multiple assistants, but an assistant to have 0 or one boss (The person with zero bosses it the head honcho).

So, your table becomes:

CREATE TABLE Persontbl( person, org,location, boss-link )
And in perl, you can store this as a simple hash with "person" as the key. The "boss-link" will be a ref to another "person", or undef.

     "A closed mouth gathers no feet." --Unknown