Vous n'êtes pas identifié(e).
Bonjour le forum,
J'imagine que cela doit être aussi simple avec Postgresql qu'avec un tableur mais je ne sais pas par quel bout commencer car je n'ai jamais fait de calculs à partir de champs disposés dans deux tuples.
Mon but c'est de faire un UPDATE sur la colonne (parcouru).
La méthode de calcul est très simple puisqu'il ne s'agit que de faire une différence de relevés entre deux dates consécutives.
CREATE TABLE comptage(
date date UNIQUE,
releve numeric(9,0),
parcouru numeric(9,0)
);
COPY comptage(date,releve) FROM stdin;
2015-12-22 7
2001-01-01 2
2016-09-22 10
\.Dans la table, les enregistrements n'arrivent pas systématiquement dans l'ordre chronologique de la colonne (date).
Si une valeur (releve) est modifiée ultérieurement, la colonne (parcouru) devra être automatiquement "updatée".
Au final, voici ce que je veux obtenir :
COPY comptage(date,releve,parcouru) FROM stdin;
2015-12-22 7 5
2001-01-01 2 0
2016-09-22 10 3
\.Je butte sur la mise à jour permanente de la colonne (parcouru) entre deux dates de relevés consécutifs.
Est-ce que la solution c'est de faire appel à une fonction? Je ne les ai encore jamais abordées.
Pour surveiller ma table, j'ai trouvé quelque chose qui me semble être un point de départ ici:
http://forums.postgresql.fr/viewtopic.php?id=3866
Merci par avance de m'indiquer comment on traite d'habitude ce genre de problème.
Dernière modification par Alain V. (04/08/2016 14:30:16)
Hors ligne
L'application doit chercher la denière valeur du relevé, puis utiliser cette information pour calculer la valeur de la colonne parcouru. Ceci fait, il ne reste plus qu'à insérer la ligne.
Guillaume.
Hors ligne
Merci pour ce retour.
1)
Pour calculer la valeur de la colonne (parcouru) je pense qu'il faut identifier la date la plus récente puis celle immédiatement avant. Je devrais m'en sortir plus ou moins élégamment.
2)
Par contre il n'y a pas à insérer de ligne puisqu'il s'agit d'un UPDATE du champ (parcouru).
C'est là que je butte : comment updater automatiquement ce champ si une valeur de la colonne (releve) est modifiée.
Hors ligne
Il n'y a qu'une seule solution à une mise à jour automatique : un trigger. Et pout ça, il vous faut coder une fonction (en PL/pgsql habituellement).
Guillaume.
Hors ligne
Je vais donc me mettre aux fonctions.
Merci de m'avoir mis sur la bonne voie car je n'en étais pas sûr.
Hors ligne
bonjour,
Est-ce vraiment utile de stocker un élément calculé ?
Si ce n'est pas le cas, pourquoi ne pas utiliser ce genre de chose :
SELECT "date", releve,
releve - lag(releve, 1) OVER (PARTITION BY 1 ORDER BY "date") as parcouru
FROMcomptage
ORDER BY "date"pour obtenir ça
date;relevé;parcouru
"2001-01-01";2;
"2015-12-22";7;5
"2016-09-22";10;3et du coup plus besoin de la colonne parcouru dans la table.
Hors ligne
bonjour,
Est-ce vraiment utile de stocker un élément calculé ?
Bonjour,
Non, ce n'est pas vraiment utile.
C'est un script Bash déclenché par une tâche Cron qui va chercher cet élément.
Il est mis dans une page html qui est envoyée par email.
SELECT "date", releve,
releve - lag(releve, 1) OVER (PARTITION BY 1 ORDER BY "date") as parcouruVoilà une structure de requête que je n'avais jamais vue!
et du coup plus besoin de la colonne parcouru dans la table.
C'est exact. Je confirme.
J'ai mis la requête dans une vue. Le script Bash va pouvoir trouver l'élément calculé qu'il a besoin.
Du coup, à part un copié/collé de la requête, je n'ai rien eu à faire.
En postant ici, je n'en demandais pas tant!
Merci beaucoup!
Je reste émerveillé devant cette requête qui fourni un élément calculé.
Je vais l'étudier de près.
Hors ligne
Je reste émerveillé devant cette requête qui fourni un élément calculé.
Je reste émerveillé devant tant d'émerveillement !!
C'est le genre de remerciement qui fait plaisir à lire !
Ce genre de requête fait appel aux fonctions de fenêtrage (window) dont la doc est ici :
http://docs.postgresql.fr/9.4/functions-window.html
C'est d'ailleurs sur ce forum, il y a quelques années qu'elles m'ont été données.
Ce n'est pas forcément évident à comprendre et à assimiler, mais ça rend des services! C'est plus efficace qu'un curseur sur les fortes volumétries.
Je dois dire qu'à chaque fois que je les utilise je me remets dans la doc, en même temps n'étant pas informaticien, je ne fais pas ça tous les jours !
Hors ligne
Je ne le fais pas non plus tous les jours, mais je suis entièrement d'accord que, quand ça arrive, c'est juste excellent 
Guillaume.
Hors ligne