Pattern for group of entities with one required primary member

Question

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?

Answer 1

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.

Answer 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.