Discussion :

[frenchsting]

L'intérêt des tableaux associatifs est de pouvoir mettre les clés que l'on veut. Un paramètre peut avoir un noms tel que VersionAppliEnCours, DernierDateMaj,... Dans ta base, tu as une rubrique clé. Tu écris qqchose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
POUR TOUT Param SUR CléParam
  TabParam[Param.CléParam] = Param.ValeurParam
FIN

Tout simplement

[Djsven]

Oui j'ai bien compris l'intérêt des tableaux associatifs, dans ton exemple, pour récupérer ensuite la valeur d'un paramètre, il suffit simplement de faire un TabParam[CléParam] avec la CléParam du paramètre en question.

Mais dans ce cas il faut connaitre précisément la "CléParam" du paramètre qu'on souhaite appeler. Si cette dernière est un numérique (1,2,3,4,5,6...), ce n'est pas ultra pratique pour se souvenir dans l'avenir que la CléParam 5 par exemple correspond au paramètre ayant pour nom "VersionAppliEnCours", c'est pour cela que je demandais s'il n'était pas plus judicieux de nommer les clés en chaine avec des noms plus explicites. Par exemple nommer la clé "PRM_VersionAppli" en BDD au lieu de la clé "5" pour le paramètre ayant pour nom "VersionAppliEnCours".

Comme ça, au lieu d'utiliser TabParam[5] pour accéder à la valeur du paramètre "VersionAppliEnCours", on ferait TabParam[PRM_VersionAppli], plus facile à lire dans le code, même s'il faudrait tout de même se souvenir précisément du nom de la clé lors de son appel dans le tableau associatif...


Après sinon il suffit d'avoir à coté un lexique de paramètres avec les différents paramètres de l'appli et leurs clés afin de pouvoir faire les bons appels mais n'y a t-il pas une méthode moins fastidieuse ?


EDIT : J'ai peut-être mal compris ton message, le "VersionAppliEnCours", "DernierDateMaj" pour ton exemple étaient le nom des clés données en BDD? Car dans ce cas, TabParam["VersionAppliEnCours"] est explicite et répond à ma question ci-dessus sur l'utilisation de clés numériques ou de clés en chaines pour le nommage des clés de paramètres

[frenchsting]

Oui, ce sont les noms des clés en BDD.

Bien sûr qu'il faut s'en rappeler de noms des paramètres, mais l'intérêt des catégories / descriptions est de t'aider à t'en souvenir.
Lors de tes dévs, à la création des paramètres, à toi d'être précis dans le nom de la description et du nom de la clé.

Subtilité qu'on a rajouté dans la fenêtre des paramètres : un bouton qui va vérifier que les paramètres sont présents en base et les crée s'ils ne sont pas là. Ca paraît bizarre dit comme ça, mais c'est utile si à fait une montée en version et que ta routine de création de paramètre a échoué.

[kunnskap]

@Djsven
L'utilisation d'une énumération sécurise le code et permet de factoriser la valeur affectée à chaque option dans la base, en plus de permettre un code beaucoup plus lisible car les noms des options apparaissent dans le code grâce à l'énumération.

[frenchsting]

@kunnskap,

Excellente idée, je n'y avais pas pensé.

[Djsven]

Bonjour,

Merci à vous deux,

Pour le nommage des clés, je vais donc partir sur des clés explicites en toutes lettres en BDD. L'idée de l'énumération est également une bonne idée, je vais utiliser cette méthode en plus en associant chaque clé à une option, même si les noms des options seront probablement identiques aux noms des clés en BDD, mais au moins Windev me proposera les différentes options lors de l'appel dans le code, ce qui évitera de me souvenir du nom exacte de la clé et d'éventuelles erreurs de saisie.


Merci à tous d'avoir pris le temps de m'aider, j'ai pas mal de pistes pour avancer et réaliser quelque chose de propre et de fiable à long terme


Bonne journée

[kunnskap]

Attention, la recherche sur des clés chaines en base n'est pas recommandée. Evidemment dans le cas d'une petite table de paramétrage ça peut passer mais il vaut mieux utiliser un entier.
Si le but visé par l'utilisation d'une chaine en base est de rendre explicite le paramètre afin qu'on voit d'un coup d'oeil a quoi il sert, il existe dans ma table de paramétrage un champ Libellé. Qui accueille à chaque sauvegarde une chaine texte, codée dans la classe, et qui décrit l'option. Au cas où on veut ouvrir le fichier on voit donc direct à quoi sert le paramètre.

Mais les codes des paramètres restent des entiers indexés en clé unique, accélérant les recherches sur des tables de paramètres plus grosses, sans sacrifier la compréhension de la table quand on l'ouvre, et tout en gardant le code sécurisé et en factorisant le code de l'option au sein du code source; de plus, inutile de changer la structure de la base, ajouter l'option dans la classe suffit.

L'inconvénient, c'est que l'ajout d'un paramètre nécessite d'intervenir sur le code et donc de redéployer, et par ailleurs, il faut ajouter l'option dans l'énum et dans la fonction qui en renvoie la description; un moindre mal à mon sens.

Je n'ai pas poussé jusqu'à externaliser le paramétrage pour le rendre dynamique afin qu'on puisse ajouter des paramètres sans redéployer mais c'est bien sur tout à fait possible, je n'en ai juste pas eu besoin.

[Djsven]

@kunnskap
Par contre en fonctionnant avec des entiers, tu réserves des plages spécifiques pour chaque catégorie de paramètres ? (Si tu utilises des catégories)
Genre la plage 1 à 20 réservée pour la catégorie 1, la plage 21 à 40 pour la catégorie 2 etc, même si tu ne remplies pas complètement ces plages ? Donc tu aurais par exemple en codes paramètres (1,2,3,22,23,24), au lieu de (1,2,3,4,5,6)
Ou bien tu incrémentes tout à la suite peu importe la catégorie ? Car par exemple, si je créé 10 premiers paramètres pour la catégorie 1 (code 1 à 10) et qu'ensuite je créé les paramètres pour la catégorie 2 à la suite (code 11 à 30 par exemple). Si je décide plus tard d'ajouter un paramètre à la catégorie 1, le code de ce dernier sera donc 31 pour mon exemple. Pas gênant pour la compréhension que tous les codes paramètres pour une même catégorie ne se suivent pas ?


Pour la description, pourquoi ne stockes-tu pas directement cette dernière en BDD en plus du libellé ?

[kunnskap]

Pour la description, oui, j'aurais pu l'ajouter à la base dans une table à part. Sur ce point y'a pas de bonnes ou de mauvaises solutions..

Pour les entiers, en effet la première façon de penser que j'ai eu c'était de gérer par plage, mauvaise idée car dès que je sors d'une plage, je suis bronzé la catégorie devient un peu anarchique car elle a des entiers qui ne se suivent plus.
Donc 2 approches, soit on fait tout à la suite, sans catégoriser, un peu chiant car les paramètres se mélangent.
Soit on catégorise les paramètres, ce qui oblige à vérifier les différentes catégories avant de décider quel entier affecter. Pour éviter les erreurs, j'ai un test automatique qui parcours l'énumération et m'avertis des doublons avant les déploiements.
Dans cette deuxième approche, les entiers ne se suivent plus pour chaque catégorie, mais aucune importance: c'est pas moi qui vais le gérer c'est la classe, donc que l'entier soit 12 ou 9452, c'est idem pour moi dans le code.

[Djsven]

L'histoire des plages, ça me dérange perso car je n'ai aucune idée du nombre de paramètres que j'aurais pour une catégorie, donc prévoir une plage au pif et être embêté ensuite, comme tu dis, ça va être l'anarchie.

J'avais également pensé à réinitialiser les codes à 1 à chaque nouvelle catégorie, donc :
Catégorie 1 : code 1 2 3 4 5 6
Catégorie 2 : code 1 2 3 4 5 6

Par contre dans ce cas, obligé de créer une clé composé (Catégorie, Code) pour avoir une clé unique car il y aura des doublons sur le code, et je vois pas comment l'affecter à l'option de l'énumération. Là actuellement, je faisais dans l'énumération Nom de l'option = "Code en base"


Pour ta deuxième approche, j'ai un peu de mal à comprendre...

[frenchsting]

Attention, la recherche sur des clés chaines en base n'est pas recommandée....

Petite question : pourquoi ?

Solution de "contournement" : dans ta table BDD de paramètres, en plus ds tes rubriques, rien ne t'empêche d'avoir un IdAuto qui te servira de clé primaire. Tu peux alors avoir un tableau associatif d'entiers avec comme clé le nom de ton paramètre et comme valeur la valeur de ta clé primaire.

[kunnskap]

@Djsven
Ah non mais les plages j'ai abandonné clairement.
La clé composée, c'est une idée intéressante mais effectivement à voir comment l'implémenter dans l'énum, chacune ne pouvant se voir affecter qu'une seule valeur. Je fais moi aussi Nom de l'option = "Code en base".

Pour la deuxième approche, je pense qu'on s'est peut être mal compris sur la notion de catégorie: c'est juste une isolation des énums dans des catégories qui sont en fait des commentaires. La catégorie n'est pas formalisée dans la base, ni dans le code.

@frenchsting: parce que chercher sur une clé chaine est moins rapide que sur un entier. Par exemple, si tu stockes la valeur "OPTNUM10", t'as besoin de 8 octets dans le champ. Alors qu'un entier n'en consomme que 4 et que la recherche sur les entiers est bien plus optimale dans une base de données, et la place occupée sur le disque sera moins grande. De plus comme les moteurs de BDD ne bossent qu'en RAM les pages à charger seront plus petites et les recherches plus optimales si le champ est plus petit. Evidemment sur des tables "petites" ça a peu d'importance et c'est juste une bonne pratique, mais sur de grosses tables, je vois déjà les carnages que ça fait sur les perfs en production.

Pour utiliser les ID primaire, on peut, mais le problème c'est qu'en cas de restauration ratée si l'ID change ou si tu dois réinitialiser les options, tu n'a pas la maitrise de tes ID primaire qui relèvent du moteur de bdd, et qui deviennent de fait imprévisibles. D'où le fait que je sois décideur du code de l'option dans l'enum. En cas de souci, j'ai la main dessus et c'est à moi de changer, mais je ne touche pas à un élément qui appartient à la base de données.

[frenchsting]

@kunnskap,

Merci pour ta réponse circonstanciée.

Dans ce cas, à la place de l'idAuto, tu prends une rubrique CodeParam entier en clé primaire, et tu la gères au moment de la création du paramètre. C'est une excellente idée.

[Djsven]

@kunnskap

Je vois pour la deuxième approche. En faite elle équivaut à la première pour les codes, tous les paramètres se suivent et se mélangent en bdd dans la table Parametre, peu importe la catégorie, mais par contre tu regroupes dans la classe les énumérations qui vont ensemble afin de t'y retrouver plus facilement.

Donc dans ma classe j'aurais :
EParametre est une Énumération
//Catégorie 1
Option = 1
Option = 2
Option = 50
Option = 75

//Catégorie 2
Option = 3
Option = 4
Option = 62

etc.


Et ensuite tu travailles uniquement avec les options donc plus besoin de gérer les codes. L'idée est bonne, je vais donc partir sur des entiers même si je ne pense pas que ma table de paramètres sera grosse. J'ajouterai par contre un code catégorie en plus dans ma table Paramètre dans le but de filtrer les paramètres sur ma fenêtre.

Merci

[kunnskap]

@frenchsting en effet et c’est la classe qui gère dès qu’on demande à set le paramètre. Le but était que je ne m’occupe jamais de la base, la classe gère tout et j’appelle ce que je veux comme paramètre avec une méthode get grâce à l’énum. Le paramètre est automatiquement crée dans la base si il n'existe pas quand je le set. Selon les besoins, on peut ensuite soit get le paramètre dès qu'on en a besoin (mais du coup, appel à la base), soit le get une fois (le paramètre est un objet) et le garder en mémoire pour éviter d'autres requêtes.

@Djsven

C’est exactement ça.

Je n’ai pas rencontré de tables de paramètres énormes, par contre, j’ai déjà vu que des paramètres soit identifié par des chaînes qui agissent comme FK dans d’autres tables. Du coup la chaine est répétée partout, fait gonfler la table et diminue les perfs.

Ce qui est difficile à comprendre et que j’ai compris grâce à une formation en SQL, c’est que ce qu’on voit dans la base ne doit pas nécessairement être humainement compréhensible. Il ne faut pas sacrifier l’art du métier au détriment de la compréhension. On le fait très bien quand on édite une facture: si elle a un statut 1 = payée, on affichera Payée sur la facture mais on stockera 1 dans la base. Pour les paramètres, c’est le même combat.

Pour la catégorie, je présume qu’une piste envisageable c’est d’utiliser un tableau associatif pour associer chaque enum (la clé, sans doublons) à une catégorie (qui est la valeur de la clé du tableau. La classe possèderait une sorte de surcouche qui permet de gérer les catégories à haut niveau, tandis que la sauvegarde d’un paramètre se ferait toujours grâce au code affecté à son énumération. Ca se fait, ça me parait pas très difficile là comme ça, faut essayer.