Ah ok, un WITH/SELECT/UPDATE doit permettre de faire ça. WITH u as (SELECT t1.id, t2.temps*1.5 as temps FROM latable t1 JOIN latable t2 ON (t2.id=t1.id-1) WHERE t1.temps IS NULL AND t2.temps IS NOT NULL) UPDATE latable FROM u SET temps=u.temps WHERE id=u.id;
L'idée c'est que le SELECT sort la liste des updates à faire et le WITH les passe à l'UPDATE... Là, le SELECT devrait sortir l'id et la valeur calculée de temps. Plus de doc sur ce "WITH" magique ici: http://docs.postgresql.fr/9.3/queries-with.html Tu va voir c'est mortel comme truc car ça peut être récursif :) Le 11 décembre 2014 19:52, didier2020 <[email protected]> a écrit : > Le jeudi 11 décembre 2014 à 18:37 +0100, sly (sylvain letuffe) a > écrit : > > On jeudi 11 décembre 2014, didier2020 wrote: > > > une troncon de route n'a pas de comptage/temps, > > > mettre a jour ce troncon en prenant comme modele les données du troncon > > > en amont/précédent avec un coef d'ajustement lié aux caractéristiques > > > des 2 troncon. > > > > Et si tu est présenté avec 3 tronçons consécutifs (t1,t2,t3) dont tu > ignores > > le temps, tu fais quoi pour t2 ? > ce n'est pas ce que désire faire, ce serait plutot > t1 et t3 connu > analyse les données de t1 et t3, puis essayer de corriger t2 > la requete n'etant la que pour ne pas creer des paliers de temps > > > Tu calculs t1 d'abord et tu repasses ton algo pour trouver t2 ? > > Et si tu as 30 tronçons consécutifs ? une.... boucle ? > > gestion des valeurs invalides ? vitesse max : -5 ou 0 ou 250 ? > > Y'a un moment où SQL ne suffit plus, ma philosophie de > développement+sgbd : > > Dès que je suis tenté de mettre un if, c'est qu'il ne faut plus faire ça > en > > SQL ;-) > > > > > > > > _______________________________________________ > dev-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/dev-fr > -- Christian Quest - OpenStreetMap France
_______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
