| Re: Table xoops_groups_users_link |
Titre du sujet : Re: Table xoops_groups_users_link
par garrath sur 14/03/2008 21:05:28
LOL
Citation :
eparcyl92 a écrit:
Bonsoir,
La table xoops_groups_users_link et constituer de:
linkid = (je ne sais pô et ce n'est pas le propos)
cette table est une table de relation entre la table group et la table user. C'est une relation avec une cardinalite 0..n des 2 cotes. Donc informatiquement cela se represente bien par une table avec normalement les cles des 2 tables en relation (donc ca c bon on l'a)
Citation :
eparcyl92 a écrit:
groupid = relier aux groupes (1=admin; 2=membre enregistré et 3=anonyme
uid = relier au xoops_users (liste des membres)
Et normalement les attributs qui peuvent etre portes par cette relation (en l'occurence la on n'en a pas)
Le probleme que tu remontes est lies a cette colonne linkid qui est un autoincrement et qui est la cle unique de cette table... donc pour la base chaque enregistrement est unique. Et effectivement fonctionnellement ce n'est absolument pas le cas.
J'ai essaye d'expliquer cela a Herve (je sais plus si c'etait cette table ou une autre mais il me semble bien que c'etait celle la) mais il a pas voulu comprendre... mieux il a essaye de m'expliquer a quoi servait une cle technique... lol
Enfin bref le probleme vient de cette colonne linkid qui ne sert a rien fonctionnellement et a rien techniquement (sauf a foutre la merde comme tu as pu le remarquer) en plus ca a tendance a ralentir le systeme. Il suffit de la virer, et de mettre en cle primaire de la table les 2 autres colonnes et le tour est joue bon avant il faut que tu supprimes les doublons, au niveau de programmes cette colonne est presente que dans la class membership et va voir elle sert a rien tu peux donc la virer sans aucun pb.
Pour supprimer les doublons c relativement simple il suffit de faire
create table temp_table as SELECT distinct groupid, uid FROM `xxxxx_groups_users_link`
ensuite tu peux supprimer la colonne dans la table groups_users_link et apres recopier les donnees dedans
Apres il y a des choix a faire
- soit tu rajoutes une cle primaire sur les 2 colonnes et donc tu n'as pas a gerer l'unicite par prg, mais il faut encore choisir l'ordre groupid, uid ou uid, groupid... ca peut avoir une importance sur des grosses tables en terme de temps de reponse en fonction des requetes qui sont faites le plus souvent on demande plus souvent la liste des gens d'un groupe ou a quel groupe appartient un user? il me semble que l on se demande plus souvent a quel groupe appartient un user et dans ce cas il faut mieux mettre uid, groupid (et en passant on peut inverser l'ordre de creation de la table) mais il faut voir...
- soit on rajoutes pas de cle primaire et dans ce cas il faut gerer l'unicite par programme dans la classe membership (et etre sur que personne n'ira mettre a jour cette table par ailleurs)
Voilà...
|
|
