refactor:completeness:replacement de l'année de creation par l'anneé obtenu de la date de création#457
refactor:completeness:replacement de l'année de creation par l'anneé obtenu de la date de création#457Tchouanga12 wants to merge 25 commits intomainfrom
Conversation
…eéobtenu de la date de création
Tchouanga12
changed the title
…re à date de création et fermeture
…ates de création comme date de début de classement
…retroactive dans le fichier apply_views
…s par station de 1806 à 2026
…s par station et classede 1806 à 2026
…angement sur la table station_creation_date
…angement sur la table station_creation_date
…angement sur la table station_creation_date
…gement sur la table station_creation_date
| SELECT COUNT(*) AS station_completeness_count FROM mv_completeness_par_station_classe_4_1806_2026; | ||
| SELECT COUNT(*) AS station_completeness_count FROM mv_completeness_par_station_classe_1806_2026; |
There was a problem hiding this comment.
Ça veut dire qu'il faut refaire une table tous les jours pour mettre à jour la completness ? Ne mets pas d'années dans le nom de la table
There was a problem hiding this comment.
D’accord, je vais modifier les noms des MV.
En principe, il n’est pas nécessaire de les mettre à jour tous les jours, car elles dépendent de l’évolution du classement des stations dans le temps.
Si la table station_classe change chaque année, alors les MV devront être mises à jour annuellement. Tout dépend en réalité du rythme auquel cette table évolue.
Pour l’instant, un calcul basé sur une date_fin correspondant à la fin de l’année en cours est suffisant. Il est inutile d’effectuer un calcul journalier du completeness, car cela entraînerait un gaspillage de ressources.
There was a problem hiding this comment.
En théorie, une station peut changer de classe du jour au lendemain, donc ça ferait rafraichir la mv tous les jours
…e nom des mv completeness
…e nom des mv completeness
|
@Tchouanga12 Tu me corriges si je me trompe, mais là ça calcule juste la completness sur la durée de vie de la station, et pas entre deux dates ? Donc qu’est-ce qu'il faudra que je fasse moi dans le code si je veux la completness entre 2 dates arbitraires ? |
|
@jlecordier Le code actuel calcule la complétude entre deux dates : une date de début fixée au 01/01/1806 (correspondant à la date de début de classement de la station la plus ancienne) et une date de fin correspondant à aujourd’hui. 
|
|
Étant donné que nous travaillons avec des timestamps, cette date devra être convertie en timestamp. |
Merci pour la confirmation |
|
Les requêtes utilisées dans les vues matérialisées sont des requêtes de base qui peuvent être réutilisées pour effectuer des requêtes sur des périodes arbitraires. |
|
J’ai fait une comparaison de l’opération de soustraction (qui est l’opération la plus fréquente dans les requêtes), suivie d’une agrégation par somme sur 5 500 lignes. Avec le casting en date, nous obtenons une prise en charge de 786 requêtes par seconde avec un temps d’attente de 12 secondes, contre 1 194 requêtes par seconde avec un temps d’attente de 8 secondes. En conclusion, l’utilisation du type date dans le calcul du completeness est bien plus performante que celle basée sur les timestamps. 
Ce test a été fait dans un meme environnement de test |
|
C'est plus rapide de faire le calcule du completeness avec les dates que avec les timestamps donc j'attends ta validation. |
|
Mhh, quand je teste tes requêtes sur la vraie base, ça prend 0.02 secondes, que ce soit avec des timestamps ou avec des dates. Donc va pour les cast en date, car le cast de l'interval en nombre est casse pied à faire. J'ai même pas besoin de faire de mv d'ailleurs, les vues suffisent |
|
OK, super : cross join + date. Plusieurs requêtes pourront être exécutées sans trop d’attente. |
|
Top, merci @Tchouanga12 Je mets la PR en draft, car on va pas la merge tout de suite, et je vais sûrement ajouter les morceaux au fur et à mesure, de manière fine |
|
D'accord, c'est noté. |
2 participants
Type de PR
Objectif
Changement de la colonne annee_de_creation à date creation du à la nouvelle données obtenu.
Contexte
La requêtes SQL implémentée au niveau de la table station_creation_date et la modification faite sur la v_station
Changements
Décisions techniques
Impacts
Tests
Points d’attention pour la review
Suivi