Comments on: I think you mean a many-to-one sir

By: James Gregory

James Gregory — Tue, 22 Jun 2010 10:53:36 +0000

Frans: Always with the logic, eh? Thanks for the comments.

The main point I was trying to get across with this post is that for 90% of the time, people genuinely do want a m:1 relationship. I have no doubt that there are situations where 1:1 are useful, but I think beginners struggle to tell the difference (primarily because 1:1 is such a vapid and overloaded term in the db space).

As for the o/r side of it, yeah, no disagreement here.

By: Frans Bouma

Frans Bouma — Fri, 11 Jun 2010 11:15:38 +0000

On the FK side, when you have an fk + uc and the fk fields are constrained by the UC, and are non-nullable, pointing to a pk, this too is a 1:1 relationship. NHibernate ignores this as if it doesn’t exist but that’s not correct. This puts people off, as the m:1 they have to map with a ‘unique’ attribute is really silly, it’s not a m:1, it’s a 1:1.

For o/r mappers internally, the 1:1 relationship is a cumbersome thing: you have to keep track which side is the fk side, and you have to check whether the fk side is constrained by a UC or a PK constraint. But that doesn’t mean it only exists in the pk-pk form, as the fk/uc-pk 1:1 is a true 1:1 relationship as well.

By: James Gregory

James Gregory — Sat, 24 Apr 2010 13:56:42 +0000

This isn’t really anything to do with HasMany. It’s for many-to-one and one-to-one relationships, which are (in Fluent NHibernate) References and HasOne respectively.

By: Mike Cole

Mike Cole — Fri, 23 Apr 2010 14:43:36 +0000

How is this mapped? HasMany mapping requires a collection, not a single object.

By: Where’s Lou » Blog Archive » Extending NHibernate data with one-to-optional relationships

Mon, 04 Jan 2010 01:51:48 +0000

[...] It’s been said that ninety percent of the time you think there is a one-to-one relationship in NHibernate it’s really a many-to-one. I’ll agree with that. But this post is about one of the ten-percent cases when a single entity spans several table schemas. [...]

By: almasmith

almasmith — Wed, 02 Dec 2009 22:53:43 +0000

Indeed, a foreign key to customer in the address table would create a one to many relationship (one customer can have many addresses).

The reason that one to one relationships are rare is due to the fact that they generally result in both pieces of information being stored in the same table (i.e. if a contact can only have one phone number then you just have a phone number column in the contact table).

James correctly demonstrated the one to one relationship having 2 tables that both share the same id.

By: Florian Fanderl

Florian Fanderl — Sun, 08 Mar 2009 11:43:47 +0000

Thank you very much for that nice explanation.

By: Tobin Harris

Tobin Harris — Tue, 27 Jan 2009 17:50:25 +0000

Yeah, I rarely see anyone make a single column both a primary *and* a foreign key.

I like the fact you get constraint checking for free: You can’t add an address if there’s no corresponding customer, and you can’t delete the customer without first deleting the address.

By: James Gregory

James Gregory — Tue, 27 Jan 2009 17:05:04 +0000

Tobin: You could do that, but I’ve never seen it done when intended to be a one-to-one; as a one-to-many yes, but not a one-to-one.

By: Tobin Harris

Tobin Harris — Tue, 27 Jan 2009 15:43:03 +0000

Nice post. You *might* be missing a foreign key constraint there.

table Customer (
Id int primary key,
Name varchar(100)
)

table Address (
Id int primary key,
Number int,
Street varchar(100),
foreign key customer_id (Id) references Customer(Id)
)

So, the address pk is also a fk to customer, enforcing that you can’t have an address without a valid customer id.