Well the rationale for using many-to-one becomes confusing when you consider that it's one-to-one on the target end if you make the relationship bidirectional. So you have a 1-1 relationship yet each end is different.
What is it then that stops <one-to-one on the target end from behaving the same way the shared primary key approach works? Presumably when it sees property-ref if then knows it's the back pointer and not a shared primary key?
Consider how elegant the JPA annotations are.. it's just @OneToOne on either end.
I know this isn't going to change any time soon I'm just surprised because to me it's non-intuitive.
christian wrote:
Quote:
The authors don't explain satisfactorily why they use many-to-one on the User end when they have a 1->1 relationship b/w User and Address.
Maybe you should read the section again. Because it's a foreign key relationship, which is a bit different than the shared primary key value of the previous section. Why you should use that? Well, maybe because you have a legacy schema that already has it?
Quote:
Are you saying that when you have an optional 1->1 relationship you should always use a jointable?
Always? No. But whenever you want to avoid a NULLable column.
Quote:
Where's the example that shows nullable foreign keys and why isn't that approach preferable?
Because NULLs are evil. Read up on why ternary logic in SQL is bad, we have plenty of references to more literature in the book.