I did a simlar project when making a system for a company to track employee's and related skills. I also had two tables and the login gave me trouble. I think this all came down to object design. As much code as i have written line-by-line as i think of it, Object design is once of the things were it pays to spend a bit of time before the code begins to flow. With what you have said, i don't think i could say the best way, as i do not presume to know everything there is about OO design or Perl. But, what i would do would probably look something like this :

my assumption: Assuming the user table has something like uid, username, passwd (crypt()'d) ... the project table, i would imagine, has project info, including something like project_id ... and would lastly guess that there is a table with something like uid and project_id which is used to pull it all together.
if this is not correct, please bear in mind this is just to show what an object might look like

$user_object = {
    'uid' => 0,
    'user_name' => 'root',
    'projects' => [ 1,2,3,4 ], # project_id's
};
[download]

Now, where to initilaize this data. I would guess that you would want to do it in the new() constructor. Assuming new() is provided a user name (or id), it should be some simple SQL to get the remaining data into the object.

You could also use a method like load() to get the data, and it may not be a bad idea to also provide that (and just have new() call it too) because the second your query for project_id's has finished, it will be incorrect (possibly). If you have stuck to OO priciples (and all info from the object is via methods), you could not hold the project data at all, and simply have the projects() method run the SQL based on the uid/user_name. That would prevent stale project data.

Once again, this is mostly opinion, but this is the general aproach i have used.

---

"They shall not overcome. Whoever told them that the truth shall set them free was obviously and grossly unfamiliar with federal law."
    -- John Ashcroft