06-04-2020, 01:57 PM
Vi, tu peux garder le created pour des questions d'historique et non de calcul. Perso, ce que j'ai comme "convention" dans ce genre de cas, c'est d'avoir une colonne "last_computation_date" ou assimilé, qui sert à faire lesdits calculs (et qui peut parfois différer d'un éventuel "last update", même si c'est rare).
Le risque avec un concat, c'est que le résultat est ensuite ré-interprété comme, ici, un INTERVAL. Ca va que tu n'as que des integers (donc je ne vois pas trop ce qu'on pourrait planter), mais imaginons que ce soient des STRING à la place, alors si la valeur "dev_duration" est "1 HOURS - 0", le concat devient "1 HOURS - 0 MINUTES + ... SECONDS" et tu manipules l'intervalle...
Ou encore (je ne sais pas si cette syntaxe serait permise), si la valeur de dev_duration est un nom de fonction, que se passe-t-il? Un dev_duration = "SLEEP(10) + 2" qui donne un intervalle "SLEEP(10) + 2 MINUTES + ... SECONDS" va-t-il faire attendre le serveur SQL pendant 10 seconds? Ce serait à vérifier via la doc de pgsql
Sinon, tu peux basculer sur du timestamp. En MySQL, tu pourrais ainsi faire:
(bon, après, ce que je trouve d'autant plus chaud, c'est le $index en plein milieu de la query qui rend le prepare un peu "inutile"; vaudrait limite mieux passer un json au SQL, et lui faire extraire le n-eme élément)
Le risque avec un concat, c'est que le résultat est ensuite ré-interprété comme, ici, un INTERVAL. Ca va que tu n'as que des integers (donc je ne vois pas trop ce qu'on pourrait planter), mais imaginons que ce soient des STRING à la place, alors si la valeur "dev_duration" est "1 HOURS - 0", le concat devient "1 HOURS - 0 MINUTES + ... SECONDS" et tu manipules l'intervalle...
Ou encore (je ne sais pas si cette syntaxe serait permise), si la valeur de dev_duration est un nom de fonction, que se passe-t-il? Un dev_duration = "SLEEP(10) + 2" qui donne un intervalle "SLEEP(10) + 2 MINUTES + ... SECONDS" va-t-il faire attendre le serveur SQL pendant 10 seconds? Ce serait à vérifier via la doc de pgsql
Sinon, tu peux basculer sur du timestamp. En MySQL, tu pourrais ainsi faire:
Code :
UNIX_TIMESTAMP + (:dev_duration * 60 + :index$index * :offset)(bon, après, ce que je trouve d'autant plus chaud, c'est le $index en plein milieu de la query qui rend le prepare un peu "inutile"; vaudrait limite mieux passer un json au SQL, et lui faire extraire le n-eme élément)