Comment cela devrait-il être conçu?

Question

Je travaille sur un projet qui permet aux utilisateurs de choisir des auteurs scientifiques et des chroniqueurs et de suivre leurs activités. Les utilisateurs peuvent suivre les activités des auteurs soit par:

1. Le choix de l'auteur explicitement et le suivi
Ou
2. Le choix d'un canal (une liste d'auteurs que d'autres pistes de l'utilisateur) et le suivi de l'ensemble du canal
Voici comment le schéma de la DB ressemble (en ce qui concerne ce cas précis d'utilisation uniquement)

DB Model http://img526.imageshack.us/img526/7278/dbmodel.png
cette conception devrait être OK dans le cas où l'utilisateur clique sur l'auteur par auteur pour suivre, l'insertion va rapidement dans la BD, et l'UI s'anime (en utilisant Ajax via Jquery) indiquant le succès ou l'échec du processus.Cependant, si l'utilisateur sélectionne un canal, les choses différeront . Voici ce que j'ai trouvé, quand l'utilisateur sélectionne un canal, j'extrais tous les auteurs de ce canal, puis j'insère de nouvelles entrées dans la table Users_Authors. Maintenant, imaginez que la chaîne contienne 1000 utilisateurs ou plus, l'insertion devrait prendre un certain temps et l'interface graphique animée ne sera pas aussi rapide que souhaité. Donc, est-ce que n'importe qui recommanderait n'importe quelle autre manière d'améliorer ceci (même si j'ai dû changer la conception entière).
Merci

Answer 1

Une chose que vous devez vous poser est la suivante:

Si l'utilisateur sélectionne un canal de 100 auteurs et que les changements de canal, ces changements devraient passer par l'utilisateur? La réponse à cette question déterminera en grande partie la conception.

Si vous voulez accréditive automatique alors ne copie pas les auteurs lorsque l'utilisateur sélectionne un canal. La conception doit prendre en charge un abonnement à un canal.

En termes OO un utilisateur zéro ou plus Subscribables, ce qui est une classe mère soit Auteur ou canal. Un canal a une relation de un à plusieurs avec les auteurs. La représentation de l'entité est fondamentalement la même. Vous avez juste besoin de faire ce qui est souscrit à un parent des deux entités.

Si vous ne souhaitez pas effectuer de modifications, vous devez soit mettre à jour le canal, soit faire ce que vous faites: copier les auteurs du canal dans les abonnements de l'utilisateur.

Answer 2

Je suggérerais une représentation différente.

En un mot, vous voulez gérer 'l'abonnement'. Il existe deux types d'abonnements: "auteur individuel" et "chaîne".

Vous pouvez donc définir une classe de base appelée abonnement et deux sous-classes, « Auteur » et « Canal », respectivement. Une ligne 'Channel' devrait être capable de maintenir une relation 1: N avec les auteurs.

Ensuite, dans la partie avant, tout abonnement sera achevé en un temps constant.

Outre cette conception la question de la maintenance des données lorsque la constituent les auteurs dans un changement de canal.

Answer 3

Vous pouvez traiter un canal comme un méta-auteur, à savoir l'abonnement à un canal est géré à peu près comme vous abonnant à un auteur. Cela vous donne deux avantages: 1. Lorsqu'un nouvel auteur rejoint une chaîne, tous les utilisateurs de cette chaîne s'abonnent automatiquement à cet auteur. 2. Peut-être qu'un utilisateur est abonné à Isaac Newton. Elle s'abonne également à la chaîne «physiciens», mais se désinscrit par la suite à nouveau. Supprimer l'abonnement "physiciens" de l'utilisateur supprimerait aussi Isaac Newton, ce qui n'est probablement pas souhaitable.

Answer 4

Mon approche serait d'avoir une table People avec à la fois les utilisateurs et les auteurs et la table Author pour n'avoir que les clés People des Auteurs. Ensuite, les auteurs créeraient une table Membres qui ressemblerait à votre table de liaison.