Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to think about the best way to handle group memberships on a website. People sign up and select checkboxes in a list of interests. Every week we send out interest-themed emails to those members that indicated that interest.

however i store the information in the database, while i am working with the lists and generating lists of email addresses or manipulating group memberships, the composite design pattern looked interesting.

it would be easy to populate the group, then do some aggregating functions that say... generate the list of email addresses based on the interests.

but i'm not sure i'm seeing any other advantages. i do need something scalable, and flexible.


share|improve this question
to be clear; i'm not looking for database storage advice, i'm learning about design patterns. Maybe this is good application of the composite one, maybe not. That is my question. – changokun Nov 13 '12 at 21:39

Design patterns apply more to code, than to databases. When you have entered the database world, you simply want a normalised database. The biggest issue you have with the composite pattern is scale: in order to manipulate those OO objects, you'd need to pull all the data from the database regardless if you need it - which is a waste and impractical if you get large lists.

In your case:

  • users: id, name, email, etc
  • interests: id, description
  • users_interests: user_id, interest_id

with the appropriate primary/unique keys. After that, you can get all of the information you need in a single database query.

For example:

  • All emails who are interested in cycling (id=2):

    SELECT email FROM users
    JOIN   user_interests ON =
    WHERE  user_interests.interest_id = 2
  • All users who are interested in IDs 2, 3, 4 and 5:

    SELECT email FROM users
    JOIN   user_interests ON =
    WHERE  user_interests.interest_id IN (2, 3, 4, 5)

However, many frameworks (e.g. CakePHP for PHP) will do this for you.

share|improve this answer
But I don't think the OP is concerned with the database. "however I store the information in the database..." – JeffO Nov 12 '12 at 1:27
I superseded that with "i do need something scalable, and flexible". If the database is fundamentally wrong, the solution will never scale. – Jay Nov 12 '12 at 1:29
Yeah, in this particular case, I'm unable to change how it is stored in the db. I'm trying to explore what design patterns might apply themselves well to groups and membership applications. i mean, you're right - if i don't use any design pattern, it will be my queries that handle who gets what. btu is there advantages to loading the entire membership? thanks! – changokun Nov 13 '12 at 21:40

Your Answer


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.