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.