If you use a foreign key for this, it becomes unique: after all, one set of many-end objects can't belong to multiple one-end objects, that's what many-to-many is for. So if you do use a foreign key, you've now got two columns that both uniquely describe the one-end object, and that's just a waste of space, redundant information, and a potential source of bugs (if, for example, you were to accidentally leave out the unique attribute on the DB column). So doing this is discouraged.
Hey, sorry to necro-post - but could anyone possibly explain this explanation for me?
I would like to understand the issues behind this statement. I often have trouble justifying my schemas to various DBAs with the explanation "the hibernate team recommends...".
We have a large number of one-to-many associations in our model and the DBAs / report writers are already moaning about surrogate keys(*). Adding a whole bunch of many-to-many link tables to map one-to-many relationships (each of which will have nothing but surrogate keys on them) is going to... cost me some DBA karma.
Are there any features of Hibernate that we will not be able to use, or that will be harder to use if we map with a simple FK relation? (**)
(*) Not really, I'm good at explaining surrogate keys these days; but we *did* have to argue for a while.
(**) We are aware of the fact that using unidirectional associations in the model will make querying harder. My question is about the statement in the documentation relating to how you map that association (FK versus link table).