[BACKEND] Création tables position_updates : suivre la mise à jour des positions AIS par MMSI

[marthevienne]

La table position_updates permettrait de stocker les dates de mise à jour des positions AIS qui ont été traitées par vessel_id.

id: UUID
vessel_id: UUID
point_in_time: datetime
created_at: datetime
updated_at: datetime

[rv2931]

Si je comprends bien le besoin c'est de stocker quelque part la date de la dernière position mise à jour
Côté fct_segments, normalement il y a la colonne "last_vessel_segment" qui correspondrait plus ou moins déjà à ce besoin
Par contre actuellement avec le fct_segment, pour faire un filtrage vessel_id/last_segment il est actuellement nécessaire de faire un join avec fct_excursion. J'ai toujours trouvé ça un peu dommage et je pense qu'il serait tout à fait envisageable de rajouter/répéter une colonne vessel_id dans fct_segment qui permettrait de ne pas nécessiter le join fct_excursion et d'utiliser last_vessel_segment qui est déjà présent
Cette problématique de join sur fct_segment je l'ai eu sur les endpoints API aussi. mettre en colonne vessel_id dans fct_excursion ET fct_segment permettrait d'optimiser par mal les performances à mon avis, c'est jamais une bonne idée de faire des joins entre 2 tables qui contiennent bcp de données
Après est-ce que ça correspondrait complètement à ton besoin ça reste à voir

[rv2931]

Déjà abordé par ailleurs, mais j'aime me répéter :)
Si on voulait être précis, et ça mérite réflexion, la vraie information "position last update" c'est spire_ais_data.spire_update_statement qui nous la donne. Toutes les autres informations point_in_time, created_at, updated_at sont en fait les dates de dernière interrogation de l'API mais la dernière position du bateau. C'est subtile mais si on voulait optimiser on ne traiterait les positions des bateaux qui ont effectivement eu une mise à jour, et non pas qui ont eu une mise à jour depuis la dernière interrogation. la différence est significative dans le cas de traitement par lot et de traitement "backfill" c'est à dire un retraitement complets des positions dans le passé

[marthevienne]

Attention, cette issue est liée à #425, je propose de se baser sur spire_ais_data.position_update_statement. Ni spire_ais_data.spire_update_statement, ni spire_ais_data.position_update_statement persistent en dehors de spire_ais_data d'où ma proposition d'avoir un suivi dans une table tierce qui permet de garder le dernier timestamp de mise à jour traité pour chaque navire : @rv2931, t'es sûr que spire_ais_data.position_update_statement ne peut pas faire l'affaire aussi ? Le comportement a l'air très similaire à spire_ais_data.spire_update_statement mais au niveau du navire.

Si je comprends bien le besoin c'est de stocker quelque part la date de la dernière position mise à jour Côté fct_segments, normalement il y a la colonne "last_vessel_segment" qui correspondrait plus ou moins déjà à ce besoin Par contre actuellement avec le fct_segment, pour faire un filtrage vessel_id/last_segment il est actuellement nécessaire de faire un join avec fct_excursion. J'ai toujours trouvé ça un peu dommage et je pense qu'il serait tout à fait envisageable de rajouter/répéter une colonne vessel_id dans fct_segment qui permettrait de ne pas nécessiter le join fct_excursion et d'utiliser last_vessel_segment qui est déjà présent Cette problématique de join sur fct_segment je l'ai eu sur les endpoints API aussi. mettre en colonne vessel_id dans fct_excursion ET fct_segment permettrait d'optimiser par mal les performances à mon avis, c'est jamais une bonne idée de faire des joins entre 2 tables qui contiennent bcp de données Après est-ce que ça correspondrait complètement à ton besoin ça reste à voir

Je suis d'accord qu'il faille ajouter la colonne fct_segment.vessel_id mais ça n'a pas de lien avec la discussion en cours (voir proposition du paragraphe au-dessus).

[marthevienne]

@rv2931 Attends, je crois que je comprends mieux pourquoi tu parles de ça : si je comprends bien, tu proposes d'arrêter d'utiliser spire_ais_data.position_timestamp au profit de spire_ais_data.spire_update_statement ?