Fluent NHibernate: rarely used properties as Component, or in seperate table?

Question

Hi,

I wonder if you could help me with something I've been thinking about. Say we have an Entity. Say the endtity has an ExtendedInfo object, which contains various properties which are not often used.

I'm wondering how best to structure this for FNH. The easiest thing to do I suppose would just set the UserInfo up as a Fluent Nhibernate 'component' of the User entity so that it is flat mapped as columns in the User table.

However, since it's not used very often maybe it would be better to store this in a seperate table, and lazy load it when required? My best guess about how to do this would be using the .HasOne mapping, but I don't know if this is the best approach.

Any thoughts on the best way to go here?

Thanks

Answer 1

The design issue:

Mapping this as a component is easier to handle, the database schema gets simpler and the handling of this class as well.

When you map it many-to-one, it needs an id. When other types are also using this UserInfo, they need to store it to the same common table. Anyway you have to care that the same instance of UserInfo is not used by several owners. This is not possible with components, you can't share UserInfo.

The performance issue:

When it is mapped as a component, it gets always loaded together with the owing type. The performance is slightly slower because it needs to read a little more data from the disk and it needs to send a little more data through the wire. Unless this UserInfo holds huge amount of data, or you intend to store millions of users, you wouldn't probably recognize it.

When you map it to a separate table, NH reads the UserInfo using a separate query. You say it is rare, but if you need the UserInfo of a large amount of users, this could significantly slow down data access. You need to optimize the query (fetch mode join), then NH will read it using an inner join. This is still slower as reading it from the same table.

To cut a long story short:

Mapping to another table (many-to-one) is quite a bit more work. It is only worth the effort if you can solve a known (!) performance issue when reading Users in a case you don't need UserInfos.