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?

  • 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, 2012 at 15:17

3 Answers 3


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.

  • +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, 2012 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, 2012 at 15:14

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.

  • 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. Mar 10, 2012 at 12:08
  • @MattiasÅslund, this is a valid point.
    – NoChance
    Mar 10, 2012 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, 2012 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, 2012 at 15:23
  • 1
    @MattiasÅslund, I am not sure this was part of the question. If this is the case, the relationship may be m-m.
    – NoChance
    May 31, 2018 at 15:46

I'll throw a third option out there. The idea of "primary" isn't so much a flag as it is a display priority:

| Entity Item           |            +----------------+
+-----------------------+            | Entity         |
| Entity Item Id (PK)   |            +----------------+
| Parent Entity Id (FK) | >----+---> | Entity Id (PK) |
| Display Order         |      |     +----------------+
| Child Entity Id (FK)  | >----+

A display priority of 1 could be considered "primary" and all others "secondary." It brings you the following benefits:

  1. If children are optional, then you don't have NULL column values taking up space in your database. You simply don't have records in the "Entity Child" table. No NULL values to deal with.

  2. You also have a specific order for things

  3. By adding a unique constraint on the Parent Entity Id, Child Entity Id and Display Order columns of the "Entity Child" table you also ensure that each entity has exactly one of each display order.

  4. If you need additional meta data about the child relationship, you can add a "Child Type" column where you could define, people, let's say, as the "Group Leader" versus "Group Member".

  5. Adding a begin and end date to each "Entity Child" record gives you the ability to track historical information about the parent-child relationships, if you need it. You could even model temporary relationships, like a "guest" to a group this way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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