Thank you very much Diego. To be honest, I don't really like any of the proposed solutions, but yours makes most sense. The only thing I don't like about it is adding so many tables to the database. I thought there was many side of <any>, and I could still access notes from IHasNotes implementations, without manually populating the collection etc. Again, thanks a lot for your time.
On Wed, Jul 14, 2010 at 4:11 AM, Diego Mijelshon <[email protected]>wrote: > Model (simplified): > > public interface IHaveNotes > { > IList<Note> Notes { get; } > > } > > public class AnyEntity : IHaveNotes > { > public virtual IList<Note> Notes { get; set; } > > } > > public class Note > { > public virtual string Text { get; set; } > > } > > > Mapping with components: > > <class name="AnEntity"> > <id .../> > <list name="Notes" table="AnEntityNote"> > <key /> > <list-index /> > <composite-element class="Note"> > <property name="Text" /> > </composite-element> > </list> > </class> > > That's really simple. Just a table per Notes collection (i.e. one table per > entity supporting Notes). > > Mapping with many-to-many: > > <class name="AnEntity"> > <id .../> > <list name="Notes" table="AnEntityNote" cascade="all,delete-orphan"> > <key /> > <list-index /> > <many-to-many class="Note"> > <column name="Note" unique="true"/> > </many-to-many> > </list> > </class> > <class name="Note"> > <id .../> > <property name="Text" /> > </class> > > You need to use many-to-many because that means the relationship is NOT > stored in the Note table, but in the specified relationship table. It > doesn't matter if the relationship is bidirectional or not. The addition of > the unique clause makes sure a note can not be associated with multiple > entities. > In this case, you have a single Note table whichs stores Note data, and a > table per collection which stores keys/indexes only. > > I believe this model and implementations will give you the best flexibility > and performance for your usage. Remember that you'll probably want to > see/update "The notes that belong to this entity" and not "The unknown > entity this note is associated to", which is the case for <any> > > Diego > > > On Tue, Jul 13, 2010 at 22:26, Vekaz Turković <[email protected]> wrote: > >> Diego, I'm sorry. I must have turned my brain off after reading "you could >> have an interface..." in you first reply. I thought you were suggesting to >> have IHaveNotes mapped and all implementations mapped as subclasses, and >> single table Notes would then reference IHaveNotes. That was the only >> mapping I could come up with and I assumed you were suggesting the same. >> >> This is your original suggestion: >> > - Note is a component type, there is one table per Notes collection >> > - Note is an entity, there is one table for the Notes and a many-to-many >> > table per each collection, mapped with cascade="all-delete-orphan" >> and I don't understand it very well since my knowledge in this area is >> very limited. >> 1. I haven't used Component before, would you care to explain exactly how >> to implement this? >> 2. I don't understand the need for many-to-many; a single Note cannot be >> attached to multiple entities. With that in mind, this would become >> "one-to-many per each collection" and Notes table would simply reference >> IHaveNotes implementations' tables, right? Or am I missing something? (I was >> going to mention performance issues again, but remembered your point #1 and >> got scared :)) >> >> I only glanced at description of <any>, but if I my assumptions about it >> are correct, it would allow me to attach a note to anything, I could still >> have IList<Note> where I needed it and navigate Notes via IHaveNotes and >> changes to the model would be slightly easier to implement (i.e. I wouldn't >> have to change the model, the db and the mappings to add or remove an >> IHaveNotes implementation. Just implement the interface and add the type to >> <any>). Am I wrong about that? >> >> I am really thankful for the time you spent helping me with this, and ask >> you to spend just a little bit more :) >> >> >> On Tue, Jul 13, 2010 at 3:18 PM, Diego Mijelshon >> <[email protected]>wrote: >> >>> Vekaz, >>> >>> 1. You first have to try a design before deciding for something more >>> complicated because of performance issues you can't measure or describe >>> 2. There is no inheritance in the proposed model >>> 3. <any> has its own problems, and, in this case in particular, I don't >>> think it's the best fit, as the relationship would be on the Note side, not >>> on the entity, so it's not easy to retrieve all the notes for an entity, >>> whereas the other model allows for navigation. >>> 4. You write the mappings once (and you can get a tool like ConfORM to do >>> most of the heavy lifting), but you use the model in many places. So it's >>> the model what needs to be simple and easy to use, not the mappings (which >>> are there to abstract the complexity of the relational implementation) >>> >>> Diego >>> >>> >>> On Tue, Jul 13, 2010 at 08:44, Vekaz Turković <[email protected]> wrote: >>> >>>> @Peter >>>> Maybe this will help: >>>> http://ayende.com/Blog/archive/2006/06/05/NHibernatesAssociationIsCool.aspx >>>> It's a bit dated but I guess it's still relevant. >>>> >>>> @Diego >>>> Nothing in particular, Diego. I don't know much about db/nhib >>>> performance, but from what I hear, having as many relationships as that >>>> design suggests, on the most frequently used tables, might cause >>>> performance >>>> issues. And, IIRC, I read somewhere that when working with inheritance >>>> queries should be given more thought than 'regular' queries, and that >>>> design >>>> would have inheritance everywhere. Why chose design that implies more >>>> thinking? :) <any> seems much more simple. Again, that's what I remember >>>> hearing/reading and isn't necessarily true, so... Feel free to educate me >>>> ;) >>>> >>>> On Tue, Jul 13, 2010 at 8:37 AM, Kenneth <[email protected]> wrote: >>>> >>>>> Yes, as Fabio wrote, use the <any> tag >>>>> >>>>> /K >>>>> >>>>> On Jul 13, 7:37 am, Peter Forstmeier <[email protected]> >>>>> wrote: >>>>> > Hi all, >>>>> > i follow this thread because i'm very interested on the same subject. >>>>> > I didn't see any solution right now. Did i miss something. >>>>> > >>>>> > Peter >>>>> > >>>>> > On 12 Jul., 13:53, Diego Mijelshon <[email protected]> wrote: >>>>> > >>>>> > > Uh? >>>>> > >>>>> > > What performance problem are you worried about exactly? >>>>> > >>>>> > > Diego >>>>> > >>>>> > > On Sun, Jul 11, 2010 at 22:50, Vekaz Turković <[email protected]> >>>>> wrote: >>>>> > > > Thank you Diego, I was afraid this will end up unanswered :) That >>>>> was one >>>>> > > > way I considered doing it, but there's also Activities who are, >>>>> > > > relationship-wise, the same as notes. Both Notes and Activities >>>>> will most >>>>> > > > probably hold a lot of data. I am afraid that, with so many >>>>> relationships, >>>>> > > > performance might become an issue pretty soon. Would it be >>>>> possible to use a >>>>> > > > denormalized database; Note would hold type and id of the entity >>>>> it is >>>>> > > > attached to? >>>>> > >>>>> > > > On Sun, Jul 11, 2010 at 11:43 PM, Diego Mijelshon < >>>>> [email protected]>wrote: >>>>> > >>>>> > > >> This was discussed last month ( >>>>> > > >> >>>>> http://groups.google.com/group/nhusers/browse_thread/thread/973df7dce.. >>>>> .) >>>>> > > >> and it is certainly on topic :-) >>>>> > >>>>> > > >> In short: the model is simple. Several classes have a collection >>>>> of notes >>>>> > > >> (or, more precisely, a List, because the order probably >>>>> matters). You could >>>>> > > >> create an interface (IHaveNotes) to deal with this in your code >>>>> and make it >>>>> > > >> easy to add/retrieve notes from any entity. >>>>> > >>>>> > > >> Then, you have at least two possible ways to map this: >>>>> > > >> - Note is a component type, there is one table per Notes >>>>> collection >>>>> > > >> - Note is an entity, there is one table for the Notes and a >>>>> many-to-many >>>>> > > >> table per each collection, mapped with >>>>> cascade="all-delete-orphan" >>>>> > >>>>> > > >> Note that the data implementation should NOT change your model. >>>>> It's >>>>> > > >> always an IList<Note>. >>>>> > >>>>> > > >> Diego >>>>> > >>>>> > > >> On Sun, Jul 11, 2010 at 08:01, moohzor <[email protected]> >>>>> wrote: >>>>> > >>>>> > > >>> Hi, >>>>> > >>>>> > > >>> This isn't strictly nhibernate related, but I thought this >>>>> would still >>>>> > > >>> be the right place to ask. >>>>> > >>>>> > > >>> I have a Note entity, related to almost all other entities (you >>>>> can >>>>> > > >>> attach a note to pretty much anything else). All these entities >>>>> have a >>>>> > > >>> property to hold a collection of notes (but notes don't have to >>>>> have >>>>> > > >>> reference to the entity they're related to). I don't know how >>>>> to best >>>>> > > >>> model this in the database and map in hbm. How would you do >>>>> this? >>>>> > >>>>> > > >>> Thanks in advance. >>>>> > >>>>> > > >>> -- >>>>> > > >>> You received this message because you are subscribed to the >>>>> Google Groups >>>>> > > >>> "nhusers" group. >>>>> > > >>> To post to this group, send email to [email protected]. >>>>> > > >>> To unsubscribe from this group, send email to >>>>> > > >>> [email protected]<nhusers%[email protected]> >>>>> <nhusers%[email protected]<nhusers%[email protected]> >>>>> > >>>>> > > >>> . >>>>> > > >>> For more options, visit this group at >>>>> > > >>>http://groups.google.com/group/nhusers?hl=en. >>>>> > >>>>> > > >> -- >>>>> > > >> You received this message because you are subscribed to the >>>>> Google Groups >>>>> > > >> "nhusers" group. >>>>> > > >> To post to this group, send email to [email protected]. >>>>> > > >> To unsubscribe from this group, send email to >>>>> > > >> [email protected]<nhusers%[email protected]> >>>>> <nhusers%[email protected]<nhusers%[email protected]> >>>>> > >>>>> > > >> . >>>>> > > >> For more options, visit this group at >>>>> > > >>http://groups.google.com/group/nhusers?hl=en. >>>>> > >>>>> > > > -- >>>>> > > > You received this message because you are subscribed to the >>>>> Google Groups >>>>> > > > "nhusers" group. >>>>> > > > To post to this group, send email to [email protected]. >>>>> > > > To unsubscribe from this group, send email to >>>>> > > > [email protected]<nhusers%[email protected]> >>>>> <nhusers%[email protected]<nhusers%[email protected]> >>>>> > >>>>> > > > . >>>>> > > > For more options, visit this group at >>>>> > > >http://groups.google.com/group/nhusers?hl=en.-Zitierten Text >>>>> ausblenden - >>>>> > >>>>> > > - Zitierten Text anzeigen - >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "nhusers" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]<nhusers%[email protected]> >>>>> . >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/nhusers?hl=en. >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "nhusers" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]<nhusers%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/nhusers?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "nhusers" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<nhusers%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/nhusers?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
