Hibernate fetching strategy - when to use "join" and when to use "select"?
Solution 1:
Join is supposed to solve the n+1 problem. If you have 10 parents, each with 10 children, join will require one query and select will require 11 (one for the parents and one for the children of each parent). This may not be a big deal if the database is on the same server as the application or if the network is really fast, but if there is latency in each database call, it can add up. The join method is a little less efficient on the initial query because you're duplicating the parent columns in every row, but you only make one round-trip to the database.
Generally, if I know I'm going to need the children of all the parents, I go with join. If I'm only going to need the children of a few parents, I use select.
Solution 2:
Select will fetch child items by issuing a new query to the database for them. Join will fetch child items by joining them into the parent's query. So that's why you're seeing similar performance, even with a drop in number of queries.
Select:
SELECT * FROM parent WHERE id=(whatever)
SELECT * FROM child WHERE id=(parent.child.id)
Join:
SELECT *
FROM parent
LEFT OUTER JOIN child ON parent.child.id=child.id
WHERE parent.id=(whatever)
As to when to use one over the other... Not entire sure. It likely depends on the database system. If one was always better than the other, I doubt they would bother to give you the option! If you're seeing similar performance for each, I wouldn't worry about it.
Solution 3:
If the parent has lots of children and those children in turn have many other, then in this case the initial 'join' might choke the network. My suggestion is to use 'select' in this case to split the selects.
Solution 4:
fetching="join" If you do fetching="join" it will retrive all the information in a single select statement.
fetching="select" if you want to paas the second select statement to fetch the associated collection than in that case you will use fetch="select".
source :Hibernate Fetching Strategies