Motif persistance - Observer à base de règles

Question

Je suis en train d'ajouter des fonctionnalités à une application où un utilisateur peut souscrire des changements faite:

• à une autre entité (par tout utilisateur)
• par un autre utilisateur (à toute autre entité)
• une combinaison des deux (ce dernier est facultatif, mais rend le problème plus difficile)

Je me demande comment mieux persister ces règles à la base de données.

Je tend naturellement vers pour chaque entité donnée (y compris l'utilisateur lui-même), j'ajouter une table UserSubscription d'addition/entité (par exemple, PublisherUserSubscription, BookUserSubscription, UserUserSubscription)

Cela signifie que les souscriptions seront persisté l'intégrité est appliquée. Cependant, il semble que cela peut rapidement balbutier en termes de nombre de tables dont j'ai besoin, et peut conduire à une conception très fragile, devrais-je changer plus tard le modèle d'abonnement. (Chaque table existante pourrait avoir besoin d'être mise à jour). Étant donné qu'il s'agit d'un scénario réaliste assez courant, je m'attendrais à ce qu'il y ait des tendances dans ce domaine. Quelqu'un peut-il en suggérer?

Answer 1

Je déteste suggérer le modèle Entité/attribut/valeur, mais pourquoi ne pas avoir une table simple comme:

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

Une table pour chaque scénario ObjectToUser/UserToObject?

Si vous souhaitez qu'une entité particulière soit observée, par exemple un livre particulier, ajoutez la clé primaire de l'objet au modèle EAV.

Ensuite, si vous avez besoin de vérifier si une règle est déclenchée, vous interrogez sur "ObjectId" de "ObjectClass" à partir de votre table et déclenchez n'importe quelle règle est répertoriée.