Is the table structure for 1:1 relations backwards?
See original GitHub issueWill try to make this as concise as possible:
Given the example above, the relation to UserInformation
is defined in my User
class. My UserInformation
rows are not really useful unless they specify a UserId
, but I’ll always be navigating from the other direction. That is to say: User
can be complete without a UserInformation
, but a UserInformation
is always incomplete when it doesn’t have a User
.
Additionally, if I set the relation up on both sides, EF gets tripped up. And really, I don’t need to specify the User
relation going back the other way as I’m always coming from the other direction.
I’m wondering if EF landed on the wrong default policy for the columns being created here. There might be a perfectly valid reason for it (let me know!), but my User
object doesn’t need to store a foreign key for 1:1 relations that it has, tables that relate to my User
almost always seem like a better spot to put the foreign key.
So, I get that I can customize this, but I’d hate to have to do this once for every 1:1 in my system. Is there maybe even just a flag I can flip to tell EF to put the foreign key on the related side, not the relating side?
Issue Analytics
- State:
- Created 7 years ago
- Comments:14 (7 by maintainers)
@atrauzzi Are you saying you think this should be interpreted as 1:1 by default? If that is the case, then everything else you say follows on from that. However, it is also valid to interpret it as 1:*, which is what EF does. At that point there is no longer any choice where to co-locate the FK–it has to be on the dependent, and that has to be the entity with the navigation property.
@ajcvickers - That doesn’t change or address any of my points about the default behaviour.
I know how it currently works, I know how the two approaches differ, that’s why I’m here.
Pretty sure I’ve been clear about this: I’m saying the way currently chosen is the less frequent and less desirable default. I do not agree at all that both approaches are effectively identical and solely down to preference.
I’ve already mentioned reasons why, and really - coming back with the same opinion seems more like a triage/discussion tactic than actually acknowledging the mistake or opportunity here.
(You can see my list of advantages above. The two approaches are not identical, so I hope laying that out here explicitly keeps people from talking past it any further.)