This is a discussion myself and some of my colleagues are having and thought I'd come out here and see what if there's a general consensus on it.
It basically comes down to the following 2 opinions on database calls:
1. Make one large call to get everything that may be needed to reduce database the number of DB calls
2. Make smaller separate calls based on what is requested to reduce the size of DB calls
Where this is especially coming into play is in common code. We'll use the example of an Employee class as that's fairly straight forward.
Let's say that your Employee class has 10 value attributes (first name, last name, hiredate, etc.) and then 2 class attributes … 1 pointing to a Department class and then 1 supervisor that points back to another Employee object.
In mindset #1, you'd make one call that returns the Employee data as well as the fields needed to populate the Department and Supervisor attributes … or at least the fields that most often used from those sub objects.
In mindset #2, you'd only populate the Employee object at first and then only populate the Department and Supervisor objects if and when they are actually requested.
2's stance is pretty straight-forward … minimize the size of the requests and how many database objects need to be hit each time one of those requests is made. #1's stance is that even if it could be implemented properly, the sheer fact that the code would have to make multiple connections is going to cause more strain on the connection between the webserver and the database as opposed to reducing it.
The driving force behind researching this is that the amount of traffic between our webserver and database server is getting out of control.
Best Answer
If the driving force behind this question is too much traffic, have you looked into caching frequently used objects? For example: AFter you get the Employee and Department and Supervisor objects, maybe it would a good idea to add them a cache so that if they are requested again in the near future, they are already in cache and don't need to be retrieved again. Of course, the cache will need to let rarely used objects expire out, and also needs to be able to remove objects that have been modified by the application and saved back to the database.
Depending on what language and frameworks you're using, there might already be a caching framework that can do some (or most) of what you need. If you use Java, you could look into the Apache Commons-Cache (I haven't used it for a while, and while it looks dormant, it is still available to use and it was pretty decent the last time I used it).