It actually is a case of premature optimization. The problem is, we're trying to build a site that on it's launch date, might get something in the order of 2M visits a month. And with our (way-too-limited) budget, we have to squeeze as much out of our hardware as possible. So we do try to write the code, from the ground up, in a way that will scale very well.

I still don't see how splitting it into separate modules will help. If you've got a server that's needs to deal with all of these objects they you'll be loading them all anyway - so you don't get a saving.

So you would create modules like Project::User::SQL, Project::Item::SQL, or just a Project::SQL?

Depends on the project.

If there was mostly a good mapping from tables to objects then I would probably use Class::DBI, or roll something similar myself. So the SQL would be handled automagically by the base-class.

If not, then I would likely use DBIx::AnyDBD to create a Project::Default module that would contain all the functions that needed to talk to the database directly. All database access would go through this module.

I might split this into multiple classes if I felt that there were parts of the database that were likely to be changed independently of each other. However, this would be very unlikely to be at the level of individual objects since I very rarely find that level of granularity useful.