Gestion Abonnement - deux tables ou une ?

[shonan]

Bonjour,

J'ai une table membre et je souhaite qu'un membre puisse s'abonner à un ou plusieurs autres membres afin d'être au courant lorsque un d'eux poste un statut.

Comme Twitter en gros.

J’hésite entre deux possibilités.

1 table membre avec un champ "abonnement"



Dans le champ abonnement je mets tous les id_user des membres dont je suis abonné en les séparants par une virgule. Et je traite l'information avec un explode en php.

Deuxième possibilité :

Je fais une deuxième table avec une clé étrangère id_user, et je rajoute l'id du membre suivi.



Exemple :
A veut s'abonner à B et C
C veut s'abonner à A
B à C

id_user...|..id_du_membre_suivi
A...........|..B
A...........|..C
C...........|..A
B...........|..C

Si on a beaucoup de membre on risque d'avoir beaucoup de lignes...

Quelle solution est la plus optimisée ?
Je ne sais pas trop comment modéliser cette situation avec un MCD.
Je dois faire une association réflective ?

Merci de m'aider

Bonne soirée

[al1_24]

C'est sans conteste la seconde solution qui est la seule bonne.
L'autre ne devrait même pas être évoquée

[punkoff]

je degagerai la colonne id_abonnement ceci dit.
Elle ne sert à rien dans ce cas précis.

[shonan]

Merci al1 et punkoff pour vos réponses.

Si j'enlève la colonne id_abonnement je mets quoi en clé primaire ? Sachant que je ne peux pas utiliser id_du_membre_suivi ou id_du_membre_abonné.

[SQLpro]

Envoyé par punkoff

je degagerai la colonne id_abonnement ceci dit.
Elle ne sert à rien dans ce cas précis.

Pas si évident (dépend de l'indexation de la PK, par exemple CLUSTERED sous MS SQL Server=... Mais il est certain que dans ce cas, une clef alternative doit impérativement être rajouté sur le couple de clef étrangères.

A +

[StringBuilder]

Bonjour SQLPro, en quoi est-ce gênant que la clé primaire soit clustered ?

En effet, lorsque je vais lire les abonnés de l'utilisateur lambda, ça me semble pas plus mal qu'ils soient tous regroupés ensemble sur le disque non ?

Bon, après en effet, si 10000 personnes décident de s'abonner d'un coup à mon utilisateur 20, SQL Server va devoir bouger toutes les données de la table, ce qui peut être préjudiciable... Mais comparé au gain lors de toutes les autres requêtes, n'est-ce pas un risque à prendre ?

[SQLpro]

Non seulement le problème que vous évoquez, mais une clef clustered sert de repère de ligne à tous les autres index ce qui fait que plus elle est grosse plus les index secondaires grossissent...

A +

[CinePhil]

Revenons à la modélisation...

Règle de gestion :
Un membre peut s'abonner à plusieurs membres et un membre peut être dans les abonnements de plusieurs membres.

MCD :
membre -0,n----abonner
|------------0,n---------|

Tables :
membre (mbr_id...)
abonnement (abn_id_titulaire, abn_id_membre_cible)

Même avec 100 000 membres qui ont en moyenne 10 abonnements, soit plus d'un million de lignes dans la table associative, en utilisant une clé de type entier auto-incrémenté pour mbr_id, et donc des entiers dans les clés étrangères, même le mauvais MySQL donnera la liste des membres auxquels un membre est abonné en une fraction de seconde.

[shonan]

J'utilise Mysql.
Du coup pas de clé primaire sur la table abonnement ?

On m'a toujours dit qu'une table devait impérativement avoir une clé primaire afin d'éviter les doublons... :'|

[Waldar]

Si bien sûr, vous avez du lire un peu vite.

Soit vous implémentez une colonne id_abonnement, qui sera votre clef primaire.
Soit vous ne l'implémentez pas et vous déclarez votre couple (id_membre_abonné, id_membre_suivi) comme clef primaire.

[shonan]

D'accord! Merci à tous pour vos réponses.

Juste une dernière question par rapport à ma table membre. C'est plus optimisé si je rajoute une table pour le sexe des membres ou je laisse comme tel ?


Tables:
membre (mbr_id...)
genre(id_genre, homme, femme)

[StringBuilder]

Ta table "genre" à 3 colonnes ???

id_genre, lib_genre

C'est mieux non ?

Evite le type "bit" pour le sexe. Sans parler du mauvais jeu de mot, le problème de bit, c'est que c'est vrai/faux/null
Un jour tu pourrais avoir besoin de rajouter un autre sexe, ce qui t'obligeras à casser toutes tes tables. Un tinyint sur 8 bits est donc tout à fait correct, d'autant que niveau représentation mémoire/traitements, ce sera plus rapide qu'un bit !

[shonan]

StringBuilder pour récupérer le genre d'une personne je serai obligé de faire une jointure avec cette méthode. Le traitement sera plus long du coup ou ça ne change rien ?

[StringBuilder]

Ca ne changera pour ainsi dire rien.
La table "genre" sera minuscule, et sans mouvement. Elle sera donc continuellement en mémoire.

Aussi, au lieu de faire une requête à chaque fois pour retrouver le sexe d'une personne, tu utiliseras une jointure, ce qui est beaucoup plus performant.

[Luc Orient]

Envoyé par SQLpro

Non seulement le problème que vous évoquez, mais une clef clustered sert de repère de ligne à tous les autres index ce qui fait que plus elle est grosse plus les index secondaires grossissent...

A +

Dans SQL Server certes, mais pas dans la majorité des autres SGBD (et en tout cas sûrement pas dans DB2 for z/OS) où c'est une référence interne qui est stocké dans les index secondaires ...

[SQLpro]

Aujourd’hui"hui la plupart des SGBDR permettent de créer des index CLUSTERED. Dernier en date PostGreSQL.

A +

[Jester]

Intéressant, je ne l'ai pas vu. Sous quelle version et sous quelle syntaxe? On aura les index only scan dans la 9.2 (mais ça reste primitif) et l'opération cluster qui ne fait que trier la table sans lier à un index.

[SQLpro]

Pour PG, tout dépend du FILL FACTOR que vous allez mettre et de la fréquence a laquelle vous allez défragmenter ou reconstruire les index.

A +

[fsmrel]

Bonsoir,

Envoyé par SQLpro

Aujourd’hui"hui la plupart des SGBDR permettent de créer des index CLUSTERED. Dernier en date PostGreSQL.

C’était en quelle année ?

Envoyé par SQLpro

une clef clustered sert de repère de ligne à tous les autres index ce qui fait que plus elle est grosse plus les index secondaires grossissent...

Le concept d’index cluster et la technique de « clusterisation » méritent d’être explicités, car les SGBD divergent à ce sujet. Par exemple, le problème que vous évoquez n’existe pas avec DB2, puisque dans son cas les index adressent tous directement les tables. Voir à ce propos les approches SQL Server et DB2 (lequel, pour mémoire, a permis la clusterisation dès le début, disons 1984).

Parfois les divergences sont bigrement sensibles, et on risque de tomber carrément dans le quiproquo. Extrait du document Présentation du système d’information ORACLE et introduction à SQL, par ORACLE France SA, décembre 1986, page 65 :

« Une autre technique pour l’amélioration des performances est la "clusterisation" (regroupement). En créant un "Cluster", vous demandez à ORACLE de juxtaposer physiquement ensemble des lignes en provenance de différentes tables. Cette technique accélère ainsi les requêtes de jointure car les lignes que vous êtes amené à rapprocher par l’opération de jointure sont déjà physiquement regroupées et stockées de manière consécutive dans une même page du disque. »

Autrement dit, le cluster (commande CREATE CLUSTER) sert ici à implanter les jointures en dur. J’avoue qu’à l’époque cela m’avait laissé, disons, septique et dubitatif, quand j’ai comparé avec DB2. Pendant ce temps là, des collègues qui utilisaient SQL/DS (frère aîné de DB2, né en 1981) pleuraient à chaude larmes car ils ne bénéficiaient pas des index cluster de son petit frère...