[R3dKap]

Aaaaah… Voilà une belle explication 😅 Merci.

La manière dont tu structure tes données est hyper importante pour faciliter et clarifier le développement de ton application.

Perso, je suis pas fan de créer des objets hyper similaires comme ça. Je préfèrerais avoir une seule liste, voire je construirai mon modèle de données ainsi :

• Une liste Compteurs qui référence tous les compteurs (qui du coup pourra porter d’autres colonnes détaillant éventuellement les caractéristiques de chaque compteur)
• Une liste Services avec les 6 services concernés par les relevés (également avec des données complémentaires si nécessaire)
• Une liste Relevés où seront stockés les relevés mensuels

Cette dernière liste Relevés, je lui donnerais la structure suivante :

• Service (qui pointe vers la liste Services)
• Compteur (qui pointe vers la liste Compteurs)
• Date (la date du relevé)
• Année (qui va contenir l’année de la date du relevé)
• Mois (qui va contenir le mois de la date du relevé)
• Valeur (qui va contenir la valeur relevée pour le compteur du service à la date précisée)

Ce modèle de données représente vraiment la réalité : c’est l’idéal. Toutes les problématiques d’accès aux données ou de volumétrie peuvent être résolus dans le code. Je vais l’expliquer…

Effectivement, le volume de la liste Relevés va être très important. C’est la raison pour laquelle il te faut alors concevoir ton application pour t’assurer que toute requête sur ta liste te ramène moins de 2000 éléments et éviter tout problème de délégation (en as-tu entendu parler ?).

C’est pour cette raison que j’ai rajouté les colonnes Année et Mois dans la liste : elles vont permettre de cibler les enregistrements à afficher dans ton application, en plus de Service (et éventuellement Compteur). En effet, dans une requête, si on avait utilisé les fonctions Year(Date) ou Month(Date) on aurait eu des problèmes de délégation. A toi de remplir ces 2 colonnes Année et Mois au moment de la création du relevé.

Concrètement, l’idée va consister à obliger l’utilisateur à choisir un service (éventuellement un compteur, mais c’est pas obligé), une année (éventuellement un mois, mais c’est pas obligé non plus). Sauf erreur de ma part, étant donné que tu as 460 compteurs (donc, en moyenne 460/6=76 compteurs par service) et que tu vas avoir un relevé par mois par compteur et par service, cela va te donner 76 x 12 = 900 relevés/compteur/service/an. Il est donc capital que ton application oblige à choisir à minima un service et une année avant d’accéder à ta liste. Toute opération de récupération de données sur ta liste devra donc à minima avoir un :

<code class="language-plaintext">Filter(Relevés; Service = … & Année = …)

C’est comme ça que l’on monte une solution propre et bien structurée (selon moi 😉).

Maintenant, ce sera à toi de faire en sorte qu’après que l’utilisateur ait choisi le service et l’année, tu récupères l’ensemble des relevés concernés pour les mettre en collection et ne travailler ensuite qu’avec la collection pour optimiser les accès à la source de données. A toi aussi de faire en sorte de récupérer en plus les relevés JUSTE sur le mois m-1 pour pouvoir calculer le delta.

Et les listes Services et Compteurs tu les charges aussi en entier dans des collections une seule fois au lancement de l’application.

Est-ce que cette approche pourrait répondre à ton besoin ?