Jeff, You are still thinking in SQL.
Of course you can map ParentId as an int property and retrieve Parents by id on demand, but there's no point on doing that. You lose capabilities and you don't gain performance; you lose it because you can't join on demand (because the relationship has not been established). Diego On Thu, Dec 17, 2009 at 17:25, Jeffry Morris <[email protected]> wrote: > Yeah, I know that n+1 can be avoided, what I am asking is if mapping a > table to entity 1:1 and implicitly ignoring any foreign key relationships > would be considered a bad practice. I am guessing it would affect 2nd level > caching, but I am not sure exactly. > > If you were using say, linq to nhibernate, would you need this mapping > since you provide any joins explicitly? For example: > > var x = from o in Order > join i in OrderItems on o.OrderId equals i.OrderIId > select i; > > So, in this case what is the purpose of having a "Has A" type relationship > between Order and List<OrderItem> unless it is a ORM specific requirement? > All I want todo is map table to entity and let the db handle foriegn key > relationship via constraints. To me, the entity is just the data. > > Thanks, > > -Jeff > > > On Thu, Dec 17, 2009 at 5:35 AM, Diego Mijelshon > <[email protected]>wrote: > >> You will not have n+1 problems because of the relationships as long as you >> use them correctly. >> For the particular case that you mentioned, if you have a ParentId, you >> don't even need to load the parent to get the children. >> >> >> Diego >> >> >> On Wed, Dec 16, 2009 at 22:06, jmorris <[email protected]> wrote: >> >>> Any advice on mapping tables directly to entities and using them as >>> pure DTOs? Basically you ignore the foreign key reference as a child >>> of the parent entity and explicitly load the children as needed: >>> select * from children where children.parentid= xxx? >>> >>> I know this goes somewhat against the ORM grain, but when most of your >>> usage is simply displaying list data, then this is a very per-formant >>> way of getting what you need an avoiding any n+1 issues with ORMs. In >>> this case your entities are just data, they are not even objects (data >>> and behavior). >>> >>> Thoughts? >>> >>> -- >>> >>> 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.
