Utilisateurs et infos connexes

[jilou]

Bonjour,
Joomla 3.8 est là et la gestion des utilisateurs est toujours aussi étriquée. Quel interet de créer une table 'profiles' alors que l'intégration de ces données dans 'users' est si simple ? Quel interet de fabriquer une table à partir d'un champ 'clé' ça me rappelle les pires constructions de style pick quand on avait des processeurs omnibus et des mémoires rikiki
que joomla laisse la place à fabrik ou autre c'est cohérent mais alors pourquoi compliquer la tache à plaisir ? sauf à devenir mortel...

[lomart]

Bonsoir,

La relation entre la table #_users et #_user_profiles est de type 1-N. Cela explique bien des choses OU je n'ai pas compris votre problème. Au fait, quel est votre problème avec cette structure ?

[jilou]

Bonsoir,
Merci de votre intèrêt
Je comprends bien ce type de relation mais joomla préviligie depuis toujours l'unicité du user donc à quoi sert ce type de relation c'est totalement obsolète aujourd'hui ou alors je ne comprends plus rien ??

[lomart]

joomla préviligie depuis toujours l'unicité du user

Oui, mais pas des informations de profil. D’où la relation 1-N

Où est le problème en dehors de l'affirmation (à mon avis erroné) que la relation 1-n serait obsolète ?
En quoi cela vous gène t'il dans l'utilisation de Joomla ? Quel inconvénient, cela entraîne t'il ?

[lefabdu51]

La table user_profiles correspond au plugin utilisateur profile et non au composant utilisateur.
La table users est la table qui contiens les champs standard Joomla et la table user_profile contient les champs optionels de chaque profil.
Ce plugin est juste la pour montrer les possibilités d extension de Joomla (bien qu il soit extremement utile à beaucoup).
C'est pour ca qu il est desactivé par défaut.

Quel interet de créer une table 'profiles' alors que l'intégration de ces données dans 'users' est si simple ?

Mis a part le fait que ce ne sont pas les memes bouts de code en action, au niveau performances du serveur sql, cela joues.
tables user = 10 champ
table user_profiles = 20 champs

Avec ton idée, recuperer le nom d'utilisateur obliges le serveur sql a parcourir une table de 30 champs, dont peu servent reelement.
A chaque requete sql, c est l'integralité de la table qui est parcourue..

[jilou]

Bonsoir,
oui bien sûr finalement j'ai écrit ce qu'il faut pour lire et afficher ce contenu additionnel
c'est juste qu'il y a des lourdeurs ailleurs et que le profil complet dans la même table c'eut été pas mal...
merci, bonne soirée

[lomart]

Bonsoir,

Si c'est réglé, merci de passer le sujet en réglé.

[cavo789]

Bonsoir,

c'est juste qu'il y a des lourdeurs ailleurs et que le profil complet dans la même table c'eut été pas mal...

Ben non surtout pas... Une table doit reste la plus petite et la plus spécialisée que possible. Si tu peux faire deux tables parce que finalement deux types d'informations (user et profil sont bien deux types différents), il faut faire deux tables.

Aussi parce que la table profil peut être remplacée par un autre composant que le natif.

Il faut à tout prix priviligié le maintenable et permettre l'extensibilité.

Et, sincèrement, que ton query interroge une ou deux tables; cela ne change strictement rien du tout.

Bonne soirée.