Don't fear the number of tables with this solution. Fear the additional complexity with the alternatives.
On Wed, Jul 14, 2010 at 3:49 AM, Vekaz Turković <[email protected]> wrote: > 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]<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.
