Comment communiquer les contraintes de clés étrangères dans une application métier?
J'ai une application commerciale avec divers formulaires commerciaux où les utilisateurs modifient les données. Lorsqu'un utilisateur supprime un enregistrement, il affiche "FK_ABC_AA .. contrainte contrainte violée, etc."
Je veux faire mieux que ça et dire aux utilisateurs quelque chose d'informatif.
J'ai vu certaines applications afficher simplement "Vous ne pouvez pas supprimer cet enregistrement car d'autres données le référencent". Ou quelque chose de ce genre. Je n'aime pas ça car ce n'est pas assez d'informations.
Je peux analyser les messages d'erreur de la base de données et afficher des messages spécifiques lisibles par l'homme, mais cela "sent" avant même que je ne le fasse. Existe-t-il un moyen préféré d'afficher ces informations?
MODIFIER:
Je dois mentionner que:
L'application ne plante pas dans mon cas. L'enregistrement n'est PAS supprimé - transaction annulée. C'est juste un message qui montre ..
La suppression des enregistrements associés n'est pas vraiment pratique dans cette situation. C'est une grande base de données de type ERP. Supposons donc que vous ayez créé un client et que vous souhaitiez le supprimer immédiatement - c'est OK. Mais vous ne voulez vraiment pas supprimer le client avec les commandes associées.
Désactiver le bouton n'est pas non plus pratique car cela nécessitera des modifications continues aux mêmes endroits que j'ajoute des relations. De plus, je dois effectuer des requêtes supplémentaires chaque fois que je récupère un enregistrement juste pour voir si je peux le supprimer.
La plupart des utilisateurs N'ONT PAS la permission de faire de la suppression, il ne s'agit donc pas d'être gentil avec tout le monde.
On dirait que c'est une application où l'utilisateur a sérieusement besoin de savoir quand une opération se déroule. Dans ce cas, vous pouvez pas vous en sortir en masquant la fonction ou en masquant le message d'erreur comme d'autres l'ont suggéré.
D'après votre description, j'en déduis que ce sont des administrateurs ou des utilisateurs de confiance qui connaissent ce qu'ils font (comme supprimer un client). Vous ne pouvez pas violer ces contraintes et vous devez exprimer l'intention de la contrainte et le plan d'action requis à l'utilisateur.
Si toutes les commandes d'un client doivent être supprimées d'un client avant de pouvoir être supprimées, dites-le à l'utilisateur (et éventuellement où cela pourrait être fait). Pensez à leur donner la possibilité de le faire tout de suite.
Donnez-leur une option Annuler (en surbrillance) et une option "Supprimer les enregistrements parents et enfants". Dans ce cas, il s'agirait de "supprimer le client et toutes les commandes associées". Expliquez-le dans les termes que l'utilisateur comprendra. Indiquez clairement ce qui se passera lorsque vous appuyez sur le bouton Supprimer si vous suivez cette route.
S'ils ne peuvent pas supprimer tous les enregistrements associés en même temps (vous indiquez qu'ils ne le peuvent pas), dites-leur ce qui doit être fait pour qu'ils puissent supprimer l'enregistrement parent. S'il doit supprimer toutes les commandes ou fermer toutes les commandes de ce client, dites-le lui. S'il s'agit d'une situation complètement impossible , désactiver le bouton Supprimer et donner une raison dans une info-bulle expliquant pourquoi cet enregistrement ne peut pas être supprimé. Il ne semble pas que cela devrait se produire souvent.
Vous dites que vous ne pouvez pas désactiver le bouton, mais vraiment tout ce que vous avez à faire est de vérifier avant et après avoir cliqué sur le bouton; si à l'ouverture d'un client vous savez je ne peux pas les supprimer quoi qu'il arrive, il suffit de désactiver le bouton. Si il semble que je puisse les supprimer, lancez une vérification après avoir cliqué sur le bouton pour voir si je peux toujours supprimer l'enregistrement; donne juste le message d'erreur si je ne peux pas. Je ne vois aucune raison pratique ou UX pour laquelle vous ne pouvez pas faire les deux.
Vous n'affichez pas ces messages à l'utilisateur en premier lieu, car l'utilisateur ne se soucie pas de savoir pourquoi vos applications ne fonctionnent pas comme prév. Ces erreurs doivent être traitées par le service QA avant de libérer le logiciel, ou, si cela est impossible, enregistrées dans le fichier journal pour un rapport de bogue supplémentaire.
Si l'enregistrement à supprimer contient des enregistrements associés dans d'autres tables, cela signifie que:
- Soit vous devez supprimer les enregistrements associés, auquel cas, faites-le.
- ou vous ne devez pas supprimer le premier enregistrement lui-même. Dans ce cas, le bouton Supprimer dans l'interface utilisateur doit être désactivé, avec peut-être une info-bulle expliquant pourquoi il est désactivé. S'il était impossible (par exemple, les enregistrements étrangers ont été ajoutés par l'autre utilisateur pendant ce temps), notifiez à l'utilisateur que l'enregistrement est impossible à supprimer.
Je suis avec svick, seulement je préfère les drapeaux de statut actif/inactif sur les entités. Non seulement vous pouvez activer/désactiver le bouton, mais également utiliser la coloration sur l'enregistrement lui-même (c'est-à-dire dans une table d'interface utilisateur) pour indiquer qu'il est actif, conserver l'intégrité référentielle, obtenir tout cela avec une simple requête et ne pas confondre Inactif avec réellement ayant été supprimé. Une table d'audit contient généralement des données telles que action = supprimé, utilisateur = certains_utilisateur, date = certains_longs, état = actif ... ou état = inactif ... donc la suppression (action) est différente de la désactivation (état).
Une autre option peut être d'avoir un indicateur sur chaque ligne qui indique s'il a été supprimé.
De cette façon, la suppression d'une ligne ne viole aucune clé étrangère. Et au cas où vous souhaiteriez "annuler la suppression" d'une ligne ou afficher des informations sur une ligne supprimée, vous le pouvez.
Ce que j'ai fait dans une application récente est de vérifier si un enregistrement peut être supprimé et de ne pas laisser l'utilisateur le supprimer à moins qu'il ne puisse être supprimé. Si cela est fait avec soin, il peut être raisonnablement efficace de le faire, et cela signifie que l'utilisateur sait simplement que cet enregistrement ne peut pas être supprimé, bien que la raison en soit sans rapport avec l'utilisateur. Avec un peu de chance, ils auront une idée des raisons, ce qui devrait les amener à explorer davantage.
Bien sûr, cela ne sera pas toujours pertinent, mais le principe selon lequel ils ne devraient être autorisés à faire que des choses sensées devrait être respecté. Vous devrez peut-être également fournir des informations ou des clics pour indiquer le problème - s'il contient des enregistrements enfants, vous souhaiterez peut-être indiquer le nombre d'enregistrements et fournir un clic pour les voir.
Mais la solution détaillée sera plus spécifique à votre application et à vos utilisateurs. La façon dont cela fonctionne pour votre application dépendra de vos spécificités.
D'accord, vous voulez donc rendre votre demande plus informative. Vous connaissez les données, vous connaissez le schéma, vous pouvez informer l'utilisateur de manière appropriée via les règles métier de votre Application:
- L'utilisateur appuie sur le bouton Supprimer
- Vous interrogez le schéma pour voir s'il existe une relation FK et des enregistrements FK
- Vous informez l'utilisateur qu'il existe des enregistrements FK et peut-être un résumé
- Donnez-leur le choix de continuer ou d'annuler
- Si l'utilisateur choisit de continuer, amenez-le d'abord à supprimer les enregistrements FK
- Si l'utilisateur choisit d'annuler, vous annulez l'action du bouton Supprimer
Je suggère de désactiver le bouton Supprimer pour les enregistrements qui ont des données associées.
Si vous pensez que l'utilisateur se soucie de savoir pourquoi il ne peut pas le supprimer, placez un bouton d'information à la place du bouton de suppression qui lui indique que l'utilisateur a associé des commandes (ou quelle que soit la raison spécifique).