-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: Aggregation(Owned Relationship) Vs Association(Referenced)
PostPosted: Thu Mar 08, 2007 1:30 pm 
Newbie

Joined: Thu Mar 08, 2007 12:59 pm
Posts: 9
Hi all,
I couldn't find any answers any where in the web so I decided to ask help here.
All veterans please feel free to post your opitions.

I am at a dillema to choose between aggregation and association.

Either way is going to work fine however,
If I use aggregation, it will be much easier since all data is going to transactioned as one. but is this going to be less efficient than
association?

my Person class has all kind of data related to it. say nick names,
bank info, credit card info, addresses info, school info, driver's license info, about total of 10-12 related collection classes.

so i don't know which way better in this case. just reference all related classes to Person or make them as composite elements.


Any opitions?


Top
 Profile  
 
 Post subject: Re: Aggregation(Owned Relationship) Vs Association(Reference
PostPosted: Thu Mar 08, 2007 3:10 pm 
Newbie

Joined: Wed Feb 21, 2007 3:35 am
Posts: 6
Not sure exactly what you mean by aggregation vs association (different people have some slightly different interpretation). However, taking your specific example:

Babo70 wrote:
my Person class has all kind of data related to it. say nick names,
bank info, credit card info, addresses info, school info, driver's license info, about total of 10-12 related collection classes.


Take person > addresses as an example.

Some rules of thumb you can consider :
a) Is there ever a need to read addresses without outside the context of the person?

If you have needs to read address directly without the person, it should have its own identity, and hence should not be a composite element under Person.


b) is an address instance ever shared by multiple entities?

Eg, if you have a need that multiple persons (such as members of a family) will share a single address, such that if one (say, the Dad) updates the address, the Mum will use the same updated address too. In that case, an address needs to be identifiable (so that it can be shared).


It is a fundamental data modeling issue (independent of using hibernate or not) that typical data modeling books / tutorial will explain it in more details. (Look for sections along the line of "What is an entity?" or "entity vs value object)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 08, 2007 4:28 pm 
Newbie

Joined: Thu Mar 08, 2007 12:59 pm
Posts: 9
OrionLee,
Thanks for your reply. let me re explain the my dilemma base on your last sentence.

you wrote
"entity vs value object"


That is essence of my question. when both can be possible,
make them value obj or seperate entity?
i would like to make them as VO, but i wonder is there any overhead
anywhere with many (10-12) collection type value objects.

I am too young to make my own judgement on this.

which mapping is better?

for example, from Person and Addresses case. they are one-to-many relation.
and No addresses are shared even thou two people live in same address
each person has to enter their own address. b/c husband doesn't know his wife information is entered and each person's information is confidential.

So my question is which one is better between these two:

<set name="addresses" table="address">
<key column="uId"/>
<composite-element class="com.hibernate.pojo.Address">
<property name="street1"/>
<property name="street2"/>
<property name="city"/>
<property name="state"/>
<property name="zip"/>
</composite-element>
</set>

or

<set name="addresses" table="address" lazy="true">
<key column="uId"/>
<one-to-many class="com.phan.hibernate.pojo.Address" />
</set>

if i go with first solution,
person.addAddress(address);
session.save(person); this will take care of two tables same time.

if i go with second solution,
person.addAddress(address)
address.addPerson(person)
session.save(person)
session.save(address)



I like first solution better but i am afraid of overhead may exists anywhere because Address is not only one of them, there will be another 10-12 classes are like Address.

they are all one-to-many relation, not many-to-one or many-to-many possible.

Is there going to be huge overhead on first solution or it's ok to do that.
or is first solution is just bad design vs second solution?

Many Thanks in Advance.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 08, 2007 5:21 pm 
Newbie

Joined: Wed Feb 21, 2007 3:35 am
Posts: 6
Ah, so your concern is primarily overhead / performance. In your case, I'd say VO would be the correct way.

Furthermore, the overhead/performance is basically identical using either mapping, provided you make the correspond tweak.

If you map it as VO (composite element), you can also make the set to be lazy as

<set name="addresses" table="address" lazy="true">
<key column="uId"/>
...

Conversely, even if you map it as an entity, you can also make save both in one call

<set name="addresses" table="address" lazy="true" cascade="save">
(and some other variants)


In short, overhead / performance can be made pretty much identical in either case.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 08, 2007 5:27 pm 
Newbie

Joined: Thu Mar 08, 2007 12:59 pm
Posts: 9
OrionLee.

Thanks. You solved my concern perfectly.

1 Credit from me.

Thank you.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.