conception de base de données pour les 'followers' et 'suivants'?

Chers de la base de données des experts/programmeurs:

J'ai une table mysql avec les utilisateurs de l'information, tels que

id      user_id         name etc.
1       userA            
2       userB   
3       userC
..      ..
..      ..

Je veux créer une fonction comme les "suivre" d'autres utilisateurs de quelque chose comme twitter. Un utilisateur peut suivre userB, ou userB peut suivre userA, ou les deux, peuvent suivre les uns les autres.
Pour cela, dois-je créer 1 table, permet de dire que les disciples

id      user_id     follower_id
1           userA       userB
2           userC       userA
3           userA       userC
4           userB       userC
5           userX       userA

Maintenant, je veux savoir qui est à la suite d'une userA. J'avais donc qqch comme:
Sélectionnez * à partir d'adeptes où user_id = userA
Cela permet de sélectionner l'utilisateur b et userC. C'est ce dont j'ai besoin.

Maintenant je veux trouver un, personnes qui userA, est le suivant (par exemple dans le tableau ci-dessus, l'utilisateur est à la suite userC et userX. Puis je devrais faire quelque chose comme
Sélectionnez * à partir d'adeptes où follower_id=userA.

Ma question est, est-ce conception de base de données pour corriger ce problème (vu dans l'esprit de la base de données de redondance et d'optimisation?) Ou il peut être mieux que cela? Merci.

  • BTW, à la suite des c'est faux
InformationsquelleAutor tcj | 2011-02-04
  1. 14

    En général, votre conception est correcte.

    Mais, si user_id est unique dans la table "utilisateurs", vous n'avez pas besoin de la colonne "id" dans "utilisateurs". (Une seule table contenant un unique "id" et un unique "user_id" est assez rare). Vous pouvez aussi ne pas besoin de la colonne "id" de la table "followers".

    Clé primaire dans des "fidèles", devrait être (user_id, follower_id), et assurez-vous que chacune de ces colonnes a une clé étrangère référençant "user_id" dans "utilisateurs".

    InformationsquelleAutor Mike Sherrill 'Cat Recall'
  2. 4

    Pointe générale. Utiliser des entiers pour les id plutôt que des chaînes de caractères. Il y a une importante différence de performances. Alors déposez utilisateurs.user_id, et de renommer les utilisateurs.id pour les utilisateurs.user_id. Deuxièmement vos disciples de tableau doivent avoir des indices sur user_id et follower_id. Là encore, il existe un important avantage de performance. J'aime aussi l'idée d'avoir un index unique sur (user_id, follower_id), demandant que votre clé primaire, et l'abandon de votre colonne id.

    • Je suis d'accord sur votre point principal que les entiers sont mieux que les primaires et les clés étrangères. Pourtant, je pense que ce qu'il a appelé user_id pourrait être quelque chose comme "nom de connexion" (et doit ensuite être renommé correctement, mais pas supprimé), une chose qui est nécessaire et doit être unique dans le système. Encore la follow table doit utiliser des références entier, juste comme vous le suggérez.
    InformationsquelleAutor btilly
  3. 3

    Voici mon dessin.

    Id    userId(PK)  followerId     followedDate         unfollewedDate
1     123         456            YYYY-MM-DD HH:MI:SS  YYYY-MM-DD HH:MI:SS
...   ...         ...            ...                  ...

    Je suppose userId - followerId combiation est unique. Les Dates peuvent être utiles. Par exemple je suis en train de réfléchir à l'utilisation si l'utilisateur unfollow et suivre à nouveau dans 5 minutes, il ne génère pas de notification. Je suppose que l'utilisateur fait par erreur. Et je peux analyser les suivantes statique par jour.

    InformationsquelleAutor Iren
  4. 1

    Oui, votre conception est la manière habituelle de traiter avec plusieurs-à-plusieurs liens. Recherche pour "la modélisation de plusieurs-à-plusieurs base de données" et vous trouverez beaucoup de ressources de vous donner des exemples de cette.

    Ajouter des clés étrangères de votre table de relation à la table des utilisateurs.

    Si votre relation implique des renseignements supplémentaires, vous pouvez mettre que des colonnes de votre connexion de la table. Peut-être, par exemple, la date à laquelle un utilisateur a commencé à la suite d'un autre.

    Séparé clé de substitution dans la connexion de la table, comme l'ID de la colonne que vous avez ajouté, peut être utile si vous voulez avoir d'autres tables de référence de votre table.

    InformationsquelleAutor Andreas Vendel