Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Given a parent entity with a collection of child entities where there must be exactly one primary child of the group?

To make the question more concrete, I've seen a number of ways that this pattern might come up -- a group of people where one person is the leader or the contact details for a person where one is primary. Here are two different approaches that I've seen.

1. Flag the member as primary In this approach, a field is added on the member to designate it as primary. The advantage is that it is simple to implement and avoids additional relationships. The disadvantage is that it is more difficult to enforce in the data model that one and only one member is primary and from an object perspective, potentially puts the responsibility on the child that should be on the parent.

2. Additional association In this approach the parent tracks the primary member of the group and stores the id of the child. This is in addition to the children storing the id of the parent as a member of the group. This makes it explicit in the data model that there is only one primary member and an index can be added to enforce it. The disadvantage is that it requires two relationships and there is a chance that they can disagree (parent points to a child that doesn't belong to the parent).

It seems to me that this is a common pattern and must be documented as a design pattern or model pattern in an architecture book somewhere. A similar pattern might be where the collection is a history and there is one current, but that is a bit easier as each member would have a date range that can be indexed. Are there better approaches? Or can someone point to where this pattern might be documented more formally?

share|improve this question
1  
I agree is a common pattern, but, no name for it. I detected as "list of options, to select", with a default option, that maybe changed. –  umlcat Mar 9 '12 at 15:17

2 Answers 2

I would go with option (1) because in addition to the features you have correctly identified, it takes little processing specially when the number of children is small. You only need to access the child table in case of Insert, Read or Update.

The problem with (2) is that whenever you update the child or insert a new primary child, the parent has to be updated. While this can be done in many ways, it looks like it has no special practical value and also, the column would not logically belong to the parent.

Other problems with approach (2):

  • Approach (2) represents a 1-1 relationship on the data model (which is usually recommended to be avoided).

  • If you delete the row designated as a primary child from the children table, what will you do for the parent row? This requires 2 updates.

This pattern is a sort of a special case from the m-m to pattern, but it would be too complex to implement an m-m pattern for this case. The special case being that the intersection table is a singleton.

share|improve this answer
1  
When your business logic changes, and your group for example suddenly need to have two equally primary leaders, the first data model needs no change. –  Mattias Åslund Mar 10 '12 at 12:08
    
@MattiasÅslund, this is a valid point. –  Emmad Kareem Mar 10 '12 at 12:12
    
@Mattias, but your logic do still need to be changed anyway. And if you may need "main" and "secondary" objects and rest? Then you have to change your boolean flag to integer that affects all classes that can be put in the list. On other hand a change on the parent object would be small and anyway the "logic" (that controls number of main elements in the list) would still most probably "reside" in the parent class that holds the list. –  Dime Mar 15 '12 at 15:22
    
"Approach (2) represents a 1-1 relationship on the data model (which is usually recommended to be avoided)." Sorry but why and who recommends this? Thanks –  Dime Mar 15 '12 at 15:23

Track the primary object on the parent object

My reason for this is that your parent object has two attributes: A list of children and a primary child. Since both are attributes of the parent object, the parent object should contain these properties.

The only time I would put an IsPrimary property on a child object is if the child object actually needed to know if it was a primary object or not, and even then child objects should not need to be aware of other child objects to maintain it's values, so a parent object should still be responsible for setting the IsPrimary property.

If you're concerned about your child objects referencing the wrong Parent object, then have the parent object set the Parent property on all children when they get added to the parent object's child collection.

As for a name for this, I don't know. Sounds like a ComboBox or ListBox - something that holds items and allows for one to be selected.

share|improve this answer
    
+1 for putting the primary on the parent as that is probably the best way to model it. You could still have the relation table to all the kids, but the parent should have a column called primary kid. –  Jon Raynor Mar 9 '12 at 20:00
    
+1 for Additional association as in this way you can store any objects in your list. With the first option, your object has to be aware that it can be stored in the list and implement an additional interface that normally it would not need. –  Dime Mar 15 '12 at 15:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.