most of the time, from the DB point of the view: it is the same. from JPA point of view, it is your choice. u build the entities tree according to ur requirements. if entity traversal is not required in the opposite direction, unidirectional will suffice.
Getting an answer here or at other software related forums will be difficult. Your question has nothing to do with the way how JPA/Hibernate maps entities and why or how you should do that.Your question is a fundamental modelling question,
Hopefully the following will not start a holy war between the RDBMS and MDA fans. If so, let's look for another forum, because I don't think this is not the right place to have such a discussion.
The question you should ask is: Do I need bi-directional assaciations in my domain-nodel. In most cases you will answer this with a certain YES.
What you're doing is mixing up conceptual thinking with implementation tricks. A DB doens't support
out-of-the-boxall kind of ralations between classes you would like to have. Things like polymorphism and inheritance are difficult to implement in DB's but thanks to Hibernate we can do a lot already. And this includes also bi-directional associations. True, there are smart ways to retrieve objects froom a DB without a defined association. That's because the bi-directional or uni-directional associations are basically implemented the same way in a DB-Table.
Let's take an example you can find in every modelling book: The relation between a Person and his/her address. Depending on the application you decide if a bi-directiponal association is useful or not. If i have a postal delivery service an Address is a separate entity and I would be interetsed to know who also lives at that addres. If I have a Client registration system I possibly wouldn't care that there are more customers at the same addres, so - in JPA terms - a Address could be an embedded address.However a commercial advertising company would be intersted in having a bi-directional relation between both entities.
Although in these three cases the DB schema could be the same, the application code is not. If you don't implement the relation between Person and Address in the model and in the final code, you're not able to go from Person to its address and the other way around in your present and future application, so you basically restict yourself, despite all kind of DB-tricks you have in your toolbox.
So - closing and repeating - don't ask yourself if you can implement smart DB-queries for bi-directional associations, but ask yourself if you need such a relation in your domain model.
Of course, my question was rather conceptual. Since everybody using Hibernate would be faced with the question of whether or not to use bidir associations, I thought it would be a good place to ask (also in the context of joins).
My thought turned out (as confirmed) that they aren't really needed - which is against my original thought when I started to learn Hibernate two months ago. I had the idea of the direction in which the joins were specified until I found out that the JPA spec actually only defines the behavior of LEFT JOINs, but not RIGHT JOINs, which would have erased many of my thought when I originally posted this.
Since I have the choice whether or not to use bidir associations, I was looking for a reason to use them at all. Technically, they aren't needed, so the answer would depend on the requirements or convenience.
Thanks for the comments from both of you. It helped.