I sense some confusion -- you describe Perl data structures, yet you then show how they could also be represented in a database.

Assuming you're going to be dealing with a database, you could have a Person with the attributes name and place_of_work, if we make the assumption that a person has just a single place of work (that is, it's a one-to-one relationship).

There are a number of ways to set up the relationship where a Person has an assistant (who is also, no doubt, a Person), depending on how your universe is structured. If one Person could have one to many assistants, but each assistant would work for just one person, then you could point each assistant to a Person (usually done with an ID). If one Person could have just one assistant, then you could get away with a single pointer, from the Person to the assistant and/or vice versa. If you go the complicated route, and multiple Persons would share multiple assistants, then you'd have to go to a releationship table where Persons would be linked to the appropriate assistants.

I would stay away from thinking about implementation details (linked lists?) until you have a firm grasp of the data structure. The best possible way to implement this is definitely in a database, whether you use something light like SQLite, or go heavier with MySQL or PostgreSQL.

The advantage with using a database is that a) the data's stored somewhere safe, b) you can use SQL to pull out exactly what you want, and c) you can try various different architectures without tearing your hair out trying to debug an array of hashes containing more arrays ... you get the idea.