DAO best practice in Hibernate: Why should you always write as few queries as possible?

Question

Hibernate

During the code review, a conflict arose on how to make the request more correctly. Decided to ask the 3rd party.
The request consists of several Entities. some of which are conditional.
suggestion number 1: first load the Entity for the conditions, and then submit them to the second request.

public ProviderMapped findByProviderId(final String providerId) {
 		Criteria c = getSession().createCriteria(ProviderMapped.class);
    c.setCacheable(true);
 		c.add(Restrictions.eq("providerId", providerId)); 
 		return (ProviderMapped) c.uniqueResult();
}

public Collection<BusinessRuleAppliedMarginByClientMarginClassMapped> findAllByProvider(final ProviderMapped provider) {
    Criteria criteria = getSession().createCriteria(getPersistentClass());
    criteria.add(Restrictions.eq("provider", provider));
    return criteria.list();
}

suggestion number 2: do everything in 1 query.

public Collection<BusinessRuleAppliedMarginByClientMarginClassMapped> findAllByProvider(Providerid providerId) {
    Criteria criteria = getSession().createCriteria(getPersistentClass());
    criteria.add(Restrictions.eq("provider.id", providerId.getId));
    return criteria.list();
}

the source code is simplified to the maximum so as not to confuse our business logic.
An important note: if you enable logs in hibernate, then we will see that in the second case, hibernate will still make two SQl queries. providerMapped is usually cacheable.
Question! what are the arguments for and against?

Answer 1

There is so much to say that it's mind-numbing.
First, a classic - don't over-optimize. You after all made measurements of an expense of resources before optimizing? This request is executed at least a couple of times per second, at least, no? Are you sure that it is this place that "eats" at least 20% of the time of the total processing time of the process? And you are aware that any software caches are nothing compared to how any "decent" DBMS can cache?
Secondly, building HQL queries. As far as I know, for One-To-Many there is no difference between an entity and its ID. You've mapped the entity, not its ID, allowing you to access the entire object when reading from the database. But this does not prevent you from using just the ID when specifying the selection criteria. You do not need to read the entity from the database at all before passing it to the HQL query, because Hibernate does not need the whole entity, it will still "take" only the ID. That is, you have an ID, but an entity is specified in the mapping - you can pass emulation to HQL - create a new Proveder (), specify an ID for it and pass the Proveder object to HQL without reading it from the database.