Great question!

Two approaches seem attractive to me. First, you could code a method that loads data from the db into an object, and provide a way to call it from the constructor. Or you could make a User::Database class to handle communications with the database.

The first option is more compact and would be quite servicable. If you have an object method that loads data from the db that is separate from the constructor, you gain some flexibility--you may want to reload a User object's data at some point. For convenience, it would be nice to be able to load data into an object when calling it. Since the load method would need to know what object to load data into, it makes sense to make load an object method.

Class methods are good for things that operate on the all the instance of a class, like an instance counter. A method that flushes all user objects to the database is a good example. You could have a class array that stores a ref to each object. Your class method User_flush_all could loop through the array and call a flush oject method on each user.

Making a User::Database class to handle db connections is a great idea. It allows you to abstract the issue of persistance. This way, if your company falls on hard times and you can't afford that Oracle server anymore, you can easily modify User::Database to use DBM files or mySQL or whatever. Of course there are the excellent DBI modules that already some of this abstraction, so it may not be worth it to separate out the persistance code. It's all a tradeoff of time/cost vs. flexibility.

As to the loading of Projects for Users, I would favor an approach where project data was loaded only when needed. Perhaps each User should have attributes for Project_IDs => [1, 2, 3, 4,]; and for Open_Projects => [Project(0x884204),Project(0x883204),Project(0x886504),]. So when you want to look at a project, you call $project = $user->open_project($project_id) which creates a new Project and adds the project to the Open_Projects array for that user. In this way you can avoid the memory bloat and startup lag of loading all a user's projects.

TGI says moo