Problème d'affichage

[atra27]

Mais pourquoi vous vous compliquez???

Faites comme sephi dit!
UPDATE tbl_post SET idposteur=NULL WHERE idposteur=idjoueurasupprimmer;

et ensuite a l'affichage:
if(idposteur==NULL){$posteurname="Membre suprimmé";}


Ton idée de garde le pseudo et id dans la base est stupide dans le sens ou tu ne libère pas de place en bdd et tu l'utilise inutilement pour des comptes fantômes!

[Sephi-Chan]

Désolé Atra mais je crois que tu n'as rien capté : supprimer l'identifiant de l'auteur du message est la pire des choses à faire puisque tu te retrouves avec des messages orphelins.

La technique que je propose est beaucoup plus simple : elle consiste à virer uniquement le pseudonyme et l'adresse email (et les autres éventuelles informations personnelles de l'utilisateur qui se désinscrit), afin de conserver la cohérence des messages. On verra juste "Utilisateur désinscrit" en lieu et place du pseudonyme.


Sephi-Chan

[niahoo]

J'ajouterais, mais je n'en suis pas sûr, que tant que tu as un tuple en base de données, la place est prise, que les valeurs valent NULL ou qu'elles soient remplies, la place étant prise à la création du tuple (puisqu'on précise les valeurs maximales pour chaque champ -- excepté pour les champs de type TEXT ou BLOB pour lesquels je ne connais pas le fonctionnement)

Dites les moi si je dis une connerie.

[atra27]

Bien dans ce cas on supprime l'user de la table user sans supprimer l'id du proprio du post.
Et a l'affichage, on fait avec un jointure pour récupérer les posts et le pseudo de leur propriétaire et si le proprio vaux NULL (jointure infaisable car le champ recherché n'existe pas) on affiche user désinscrit.

Mais dans tous les cas on supprime l'user de la table user!

[Sephi-Chan]

Bien dans ce cas on supprime l'user de la table user sans supprimer l'id du proprio du post.
Et a l'affichage, on fait avec un jointure pour récupérer les posts et le pseudo de leur propriétaire et si le proprio vaux NULL (jointure infaisable car le champ recherché n'existe pas) on affiche user désinscrit.

Mais dans tous les cas on supprime l'user de la table user!

Mais… Qu'est-ce que ça apporte de faire ça ?

On est pas en mode crevard de l'octet, là. Et puis le résultat sera le même : toutes les ressources associées à un utilisateurs se retrouve orphelines. J'ai du mal à vous suivre… Pourquoi voulez-vous faire dans le compliqué et inefficace ?


Sephi-Chan

[atra27]

Tu propose donc de laisser le champ dans la table et de juste pas l'afficher? intérêt? tu as peut être raison mais j'en vois pas la donc si tu pouvais préciser...

[Sephi-Chan]

Je propose de rendre le compte anonyme en supprimant l'email et le pseudonyme de l'utilisateur. Ainsi, l'identifiant reste le même. Les messages de l'utilisateur #23 restent les messages de l'utilisateurs #23, c'est juste que maintenant, on ne connaît plus son nom. Ça évite de rendre les ressources associées à cet utilisateur orphelines et donc moins pratiques à administrer. On conserve ainsi une base de données cohérente.

Maintenant, à mon tour de te demander l'intérêt de ta démarche.


Sephi-Chan

[atra27]

ben simplement gagner de la place, je trouve inutile de garder un champ sql pour les users supprimés (imaginez un bot qui s'inscrit 1000 fois?)
Ensuite parce que si on dis qu'on supprime, alors on supprime vraiment le compte!

Avec ton système, tes données "plus faciles a administrer" tu te retrouvera quand même avec des utilisateurs inconnus dans ton interface admin.
Tu pourra toujours les retrier par id de propriétaire mais finalement ma solution peut faire la même chose vu qu'on garde l'id dans le champ du message.

Garder la cohérence de la bdd... pour moi un post est lié a son forum et a son rédacteur.
Si tu supprime le rédacteur, tu te retrouve avec un post sans rédacteur mais il te reste toujours le lien qu'il a avec le forum.

Donc pas de risques de post "ghost" (en bdd mais liés a rien)

Je ne comprend pas vraiment pourquoi tu tiens absolument a garder l'enregistrement de l'user vu que de toute façon une fois anonymé, tu te retrouvera quand même avec une liste de posts qui on un user "indéfini"

Ensuite imagine tu supprime les messages de plus de 60 jours, au bout de 60 jours, un compte supprimé se retrouvera sans aucun message... (logique) pourtant l'enregistrement de l'user restera en bdd totalement inutilement! et tu te retrouvera donc a garder des entrées sans nom et sans post (donc totalement inutiles!)

Tu vois mon point de vue?

[Sephi-Chan]

Exact, je comprends ton point de vue. Mais je n'y vois aucun avantage pour autant.
En supprimant la ligne de l'utilisateur, je ne pourrais plus utiliser d'ORM, exemple :

@user = User.find(params[:id]) # Ne fonctionne pas si on a supprimé l'utilisateur d'ID donné !

# Adieu les @user.posts, @user.votes, @user.profile, etc.

De plus, si ton modèle de donnée est correctement construit, la cascade fera que la suppression d'une données supprimera les références associées (par le principe des foreign keys). Ta solution repose donc un modèle de données sans cascade : ce n'est pas propre du tout.


Sephi-Chan

[atra27]

comment tu peut avoir besoin de find un user qui a été supprimé? :p

Et si ta fonction est bien faite, elle va alors rechercher l'id de l'user dans les messages privés, les posts du forum et la table user!
Il manquera juste la table user et le pv mais elle te retournera quand même les messages forums correspondants!

Ou est ton probléme?