views:

95

answers:

1

I'm trying to add functionality to an app where a user can subscribe for changes made either:

  • To another entity (by any user)
  • By another user (to any other entity)
  • A combination of the two (this last one's optional, but makes the problem more challenging)

I'm wondering how best to persist these rules to the database.

I'm naturally tending towards for each given entity (including the user itself), I add an addition UserSubscription table / entity (eg, PublisherUserSubscription, BookUserSubscription, UserUserSubscription)

This means that subscriptions will be persisted with integrity enforced. However, it seems that this can quickly baloon in terms of the number of tables I'll need, and can lead to a very brittle design, should I later change the subscription model. (Every existing table could need to be updated).

Given this is a fairly commonplace real-world scenario, I'd expect there'd be some patterns around this. Can anyone suggest some?

+1  A: 

I hate to suggest the Entity/Attribute/Value pattern, but why not have a simple table such as:

rulename    Observer   ObjectClass  ObjectId
========    ========   ===========  ========

One table for each scenario ObjectToUser/UserToObject ?

If you want to have a particular entity be observed, say a particular book, have the Object's Primary Key be added to the EAV pattern.

Then if you need to check if a rule is fired, you query on "ObjectId" from "ObjectClass" from your table and fire whatever rule is listed.

Chris Kaminski