Let's say I have a simple parent/child relationship in 2 tables. Imagine the parent table has 4 rows and the child table has dozens of rows. When I use nhibernate to read the object graph, it issues 5 select statements - 1 to read the parent rows and then 1 each to read the children for each of the parents!

This is inefficient... there should only be 2 select statements and 2 round trips to the database. One to read the parent rows, and one to read all children of all parents (using a simple "in" clause). Then loop through the children, assigning them to the proper parent.

So if I have hundreds of parent rows, nhibernate is going to sit there making hundreds of round trips to the database. I don't understand this, I doesn't really give me a good feeling about what happens under the covers when I use this O/R solution.

Nobody has any comment on this, I guess it is no big deal that nhibernate thrashes your database?

This kind of remarks isn't going to encourage anybody to help you.

NHibernate allows you to load parents and children more efficiently. Read the documentation on batch fetching and querying.

I have the same problem, trying to use batch or fetch didnt help.

Could you give us some hints for the basic example above ? (I do not support the above aggressiveness either :-))

You can map the Children collection of Parent with batch-size="4" for example. Or you can use a query like "from Parent p join fetch p.Children where p in (:someIds)". If you have trouble with it, post your code, mappings, and possibly also logs.

Thank you for the help. Your answer was helpful and did address my concern.

After examining the log4net output, I was wondering, with all due respect, why not concat a string with an IN clause of the parent ID's? It seems this would be much more speedy than using a hundred named parameters all combined with OR statements.

But, I am still just a beginner so I'm not sure if there is a reason for this (i.e., the dialect?)

Multicolumn primary keys would have to be handled using "... OR ... OR ..." style anyway, that's why IN is not used. And concatenating SQL is bad in general, so parameters are used. But I didn't write the code myself, so these all are just my educated guesses.