Configurer vos listes de choix

Avec les listes de choix (liste déroulante, à puces…) se pose la question du référentiel des données : dois-je stocker l’ID ou la valeur ? Nous allons présenter dans cet article les deux solutions avec leurs avantages et inconvénients. Notons que cela n’est pas directement lié à K2, pourtant la problématique est présente très souvent et trop peu étudiée.

Prenons l’exemple d’une demande de déplacement, où la destination est proposée à travers une liste de choix dans une liste de villes ; dont une ville est caractérisée par un ID, un nom, un pays (dans lequel se trouve la ville). 

Stocker la valeur

En stockant la valeur de l’élément sélectionné (le nom de la ville), j’assure les points suivants :

  • L’affichage est rapide. il n’est pas nécessaire d’interroger l’objet ville, uniquement l’objet demande de déplacement.
    • En revanche, si je veux savoir dans quel pays se trouve ma ville, l’appel ne sera pas “propre” et si 2 villes ont le même nom, c’est perdu.
  • Dans le cas où le nom d’une ville change (pourquoi pas… Paris devient Paris2), les anciennes demandes qui concernaient à l’époque Paris ne seront pas impactées par le changement.
    • En revanche, s’il y a une faute d’orthographe dans une ville et qu’elle est corrigée, les données dans les anciennes demandes ne seront pas mises à jour automatiquement.
  • Dans le cas où une ville disparaît de la liste des villes (ok ce n’est pas le meilleur exemple…  mais projetons nous dans ce cas, avec une liste de produits à vendre, ce sera plus politiquement correct ), les anciennes demandes ne seront pas corrompues.

Stocker l’ID

En stockant l’ID de l’élément sélectionné (l’ID de la ville), j’assure les points suivants :

  • L’affichage est légèrement moins rapide. Il est nécessaire d’interroger l’objet ville (pour récupérer le nom) en plus de l’objet demande de déplacement.
    • Et si je veux savoir dans quel pays se trouve ma ville, l’appel est déjà fait ; si 2 villes ont le même nom, cela ne pose pas de problème (les IDs étant différents).
  • Dans le cas où le nom d’une ville change, les anciennes demandes seront impactées par les changements. S’il y a une faute d’orthographe dans une ville, les anciennes demandes seront corrigées.
    • Dans le cas où il faut garder la trace d’un changement, on peut ajouter un élément plutôt que le modifier.
  • Dans le cas où une ville disparaît de la liste des villes, il ne faut pas la retirer de la liste mais ajouter une gestion Actif/Inactif à la place. Sinon les anciennes demandes seront corrompues.
    • les villes inactives ne devront pas être sélectionnables dans les nouvelles demandes.

Conclusion

Les avantages de la première solution sont les inconvénients de la deuxième et inversement. Stocker la valeur est plus simple à mettre en place mais trop rigide pour des liaisons entre deux objets complexes (comprenez deux objets ayant chacun plusieurs propriétés : Id, Nom, Propriete1…). Stocker l’ID demande un peu plus de travail mais en résulte une solution plus pérenne, plus “propre”.

Dans la pratique, les listes de choix globalement statiques (homme/femme, oui/non…) peuvent stocker directement la valeur, pour les autres notre recommandation est de stocker les IDs !

C’est tout pour cette fois, cheers !

benjamin

Technical Specialist @t K2 France ----- Twitter : @benjaminbertram ----- LinkedIn : Benjamin Bertram

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.