Question

Je développe une galerie qui permet aux utilisateurs de publier des photos, des commentaires, voter et faire beaucoup d'autres tâches.

Maintenant, je pense qu'il est correct pour permettre aux utilisateurs de se désabonner et supprimer toutes leurs données si elles le souhaitent. Cependant, il est difficile de laisser une telle chose parce que vous courez le risque de casser votre application (par exemple, que dois-je faire quand un commentaire a beaucoup de réponses? Que dois-je faire avec les pages qui ont de nombreuses révisions par différents utilisateurs?).

Les photos peuvent être facilement enlevés, mais pour d'autres données (à savoir des commentaires, des révisions ...) Je pensais qu'il y a trois possibilités:

  • l'assigner à l'administrateur
  • l'assigner à un utilisateur appelé « utilisateur supprimé »
  • mantenir les associations actuelles (à savoir l'ID utilisateur) et seulement renommer les données de l'utilisateur (par exemple, attribuer un nouveau nom d'utilisateur tel que « -24 retiré par l'utilisateur » et un e-mail tels que « noreply-retirée-user- inexistante 24@mysite.com "

Quelles sont les meilleures pratiques à suivre lorsque nous permettons aux utilisateurs de supprimer leurs comptes? Comment les mettre en œuvre (en particulier dans Rails)?

Était-ce utile?

La solution

Idéalement situé dans un système que vous ne voudriez pas « supprimer » dur données. La meilleure façon que je connaisse et que nous avons mis en œuvre dans le passé est « douce suppression ». Maintenir une colonne d'état dans toutes vos tables de données qui renvoie idéalement au fait si la ligne est active ou non. Toute ligne lors de sa création est par défaut « active »; Cependant, comme les entrées sont supprimés; ils sont rendus inactifs.

Toutes les requêtes de sélection qui affichent des données sur les résultats du filtre d'écran pour seulement « enregistrements actifs ». De cette façon, vous obtenez les avantages suivants: 1. Récupération de données est possible. 2. Vous pouvez avoir une tâche planifiée au niveau de la base de données, qui peut prendre en charge les suppressions difficiles d'une fois d'une manière; si vraiment nécessaire. (Comme une procédure SQL ou quelque chose) 3. Vous pouvez avoir un écran d'administration pour être en mesure de décider quels comptes, entrées etc vous avaient vraiment envie de marquer pour la suppression 4. invalidante temperory de compte peut également être mis en œuvre avec la même solution.

Dans les environnements prod où j'ai travaillé, un disque de suppression est un strict non-non. Enfait audits sont maintenus pour supprime également. Mais si l'application est vraiment petit; ce serait jusqu'à l'utilisateur.

Je voudrais encore suggérer une « suppression virtuelle » ou un « soft suppression » avec le nettoyage périodique au niveau db; qui sera beaucoup plus rapide et efficace optimisée de nettoyage.

Autres conseils

Je suis généralement résolu ce type de problème en ayant un indicateur actif de l'utilisateur, et la mise simplement actif à false lorsque l'utilisateur est supprimé. De cette façon, je maintiens l'intégrité référentielle dans le système même si un utilisateur est « supprimé ». Dans la couche d'affaires je valide toujours un utilisateur est actif avant de leur permettre d'effectuer des opérations. Je filtre également les utilisateurs inactifs lors de la récupération des données.

La chose habituelle à faire est au lieu de les supprimer à partir d'une base de données, ajouter un champ de drapeau booléen et ont il est vrai pour les utilisateurs valides et faux pour les utilisateurs non valides. Vous devrez ajouter du code pour filtrer sur le drapeau. Vous devez également supprimer toutes les données pertinentes de l'utilisateur que vous pouvez. L'objectif principal de ce drapeau est de garder les liens intacts. Il est une variante des données changement de nom de l'utilisateur, mais le drapeau sera plus facile à vérifier.

Je n'aime généralement pas supprimer quoi que ce soit et au lieu d'opter pour marquer les enregistrements en utilisant comme supprimés / non publiés états (avec AASM à savoir agit comme machine d'état).

Je préfère les états et les événements à utiliser simplement des drapeaux que vous pouvez utiliser des événements pour mettre à jour les attributs et envoyer des e-mails, etc. d'un seul faute. Vérifiez ensuite les États de décider quoi faire plus tard.

HTH.

Je recommande de mettre dans un champ de date de suppression qui contient la date / heure à l'utilisateur désabonné - non seulement à l'enregistrement de l'utilisateur, mais à toutes les informations relatives à cet utilisateur. L'application doit vérifier le champ avant d'afficher quoi que ce soit. Vous pouvez ensuite exécuter un disque supprimer tous les enregistrements de 30 jours (heure de votre choix) après la date de suppression. Cela permettra à l'information ne doit pas être montré (vous aurez probablement besoin de mettre à jour l'application dans quelques endroits), le temps de permettre à l'utilisateur de se réabonner (accidentelle ou repensant) et un processus prévu pour supprimer les anciennes données. Je supprimerais toutes les informations sur le membre et des commentaires connexes sur le membre ou les données publiées avant (photos, etc.)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top