Pourquoi pas. On peut faire des tableaux à plusieurs dimensions. Dans l'exemple il est facile de déduire des noms de données que l'on veut gérer une table des notes des élèves par trimestre et mois dans le trimestre, soit :
1
2
3
4
|
01 COTATION-EXA.
02 TRIMESTRE OCCURS 4 TIMES.
03 NOTE-ELEVE PIC 99V99 OCCURS 3 TIMES. |
On a donc un tableau des trimestres, donc 4 occurrences, chacune décomposées par les 3 notes mensuelles de l'élève pour le trimestre. Au plan réservation mémoire il reviendrait au même de déclarer :
1
2
3
|
01 COTATION-EXA.
03 NOTE-ELEVE-MOIS PIC 99V99 OCCURS 12 TIMES. |
C'est cependant fonctionnellement différent. Dans le premier cas on accédera à une note d'après le trimestre et le mois dans le trimestre (donc OBLIGATOIREMENT via 2 indices, du niveau le plus haut jusqu'au plus bas (inversement proportionnel au niveau de la picture COBOL)
ex: MOVE NOTE-ELEVE(MY-TRIMESTRE,1) to NOTE-ELEVE-MOIS1-DU-TRIMESTRE
Dans le second cas on accédera directement par le mois
ex : MOVE NOTE-ELEVE(1) to NOTE-ELEVE-JANVIER
Maintennant, même si la réservations mémoire est identique, quand on peut éviter de multiplier le nombre de dimensions d'un tableau, c'est mieux pour les performances, mais c'est un exemple basique, dans la réalité des besoins fonctionnels ce n'est pas si toujours si simple. Dans le cas présent il est évident qu'il suffisait de recalculer le mois d'après le trimestre et le mois du trimestre pour pouvoir travailler avec un indice simple
qque chose du genre :
Compute MY-MOIS = ((MY-TRIMESTRE * 4) + MOIS-TRIM ) -4)
Move NOTE-ELEVE(MY-MOIS) to NOTE-ELEVE-MOIS1-DU-TRIMESTRE
Mais quelque part on voit bien que la lisibilité du code s'en ressent.
Nb, j'ai vu au dernier moment qu'une réponse venait d'être ajoutée. Celle-ci fait double emploi mais je vais tt de même l'envoyer rien que pour la reflexion sur les compromis choix fonctionnels lisibilité du code et performances
Question sur les tableaux
Répondre avec citation
Envoyé par beegees
Partager