Est-il correct de ne supprimer que parfois un modèle?
Je développe une sorte de CMS. Dans ce document, les utilisateurs peuvent créer des "clients". Pour une raison quelconque, un utilisateur peut vouloir supprimer ce client. Peut-être parce que le client a été créé par erreur, ou peut-être pense-t-il que le client ne reviendra plus jamais, ou peut-être qu'il est simplement OCD et veut un système propre et agréable.
Cependant, les clients sont référencés à divers endroits du système. Par exemple, les réservations sont liées aux clients. Si un client est lié à une réservation puis supprimé ultérieurement, la réservation sera essentiellement corrompue. Il manque maintenant une information vitale historique. Pour éviter cela, j'ai créé des contraintes de clé étrangère au niveau de la base de données.
Voici ce que je pense: je peux tirer parti de ces contraintes en tentant de supprimer le client à la demande, mais en cas d'échec, effectuez une suppression logicielle à la place. De cette façon, je peux maintenir l'intégrité référentielle, mais aussi empêcher l'accumulation de corruption de clients supprimés en douceur qui ne sont réellement utilisés nulle part.
Récapituler:
- Si un client est pas référencé n'importe où dans le système, il effectuera une véritable suppression matérielle
- Si le client est référencé quelque part, il effectuera une suppression logicielle (c'est-à-dire marquera l'enregistrement comme supprimé mais le conservera)
Est-ce correct? Ce qui m'inquiète, c'est que vous ne savez pas vraiment ce que fera le bouton "Supprimer" jusqu'à ce que vous appuyiez dessus, mais du point de vue d'un utilisateur, cela n'a pas vraiment d'importance - de toute façon le Client disparaîtra de l'index. Y a-t-il d'autres problèmes?
Du point de vue de l'utilisabilité, c'est essentiellement la même chose pour l'utilisateur, que la suppression logicielle ou matérielle soit utilisée: l'enregistrement est parti.
Ce n'est pas la vérité absolue, cependant, si le client supprimé est accessible via la réservation, il est lié. C'est quelque chose qui doit être planifié, par exemple est-il correct de simplement montrer au client sans fonctionnalité complète d'interagir avec lui.
Je dirais que pour la plupart des systèmes, la norme consiste à ne jamais supprimer réellement les enregistrements, mais uniquement à les masquer avec un indicateur comme votre idée. Même les grands joueurs comme Google et Facebook ne suppriment jamais rien .
Cela ne semble pas vraiment être une question UX, car du point de vue UX, le client ne peut pas faire la différence.
Mais si cela aide, du point de vue de la conception du système, permettre à une dépendance relationnelle de dicter votre politique de conservation/suppression des données n'est pas une bonne pratique de conception (cela permet à la "queue de remuer le chien"). Faites-le pour plus de commodité si vous n'avez pas le temps d'écrire la propagation de suppression pour le moment, mais à long terme, je pense que vous êtes mieux servi en déterminant quelle politique convient à l'entreprise, puis en écrivant la logique de suppression (ou de suppression logicielle) en conséquence. Les suppressions partielles peuvent être utiles, mais elles entraînent leurs propres coûts (par exemple, la gestion de l'étendue des données irrégulières/incohérentes).
La décision commerciale peut dépendre, entre autres, du coût de stockage, de la confidentialité des clients et de vos besoins d'analyse interne (par exemple, les séries chronologiques ou l'analyse comportementale sont difficiles à faire si vous supprimez les données). Notez simplement que la confidentialité peut être gérée si vous souhaitez conserver les enregistrements ... Vous pouvez, par exemple, anonymiser les données client lors d'une suppression logicielle.