When we have a model where an entity has some properties collections used for displaying it to the customer and we are not querying our data by these properties at all, it may seem right to map these collections in NHibernate as collections of components. Component in NHibernate is an object without its own identity, being a part of its parent entity. Our collections sounds similiar in terms of lifetime and ownership, but different in terms of relationship - these are one-to-many. In complex scenarios, additional queries became a serious issue. We've decided to try another solution - it's so simple that it can't go wrong.
Moreover, tables generated by NHibernate for the components doesn't have primary key. This is pretty obvious, but it's generally a bad practice and can be a performance pitfall when used in transactions, as transaction logs can't work with full efficiency without primary key. Cost of serializing and deserializing is equal to string concatenation cost - I don't have any benchmarks, but I believe it is a level of magnitude faster than additional database roundtrip.
I would imagine that for 10-15 rows your solution would work ok, but beyond that I think it would just get slower and slower (not to mention you have to lock all that data just to update a part of it, and that you run the risk of accidentally destroying all of it).
Thanks for sharing!