sql : calculer la différence entre 2 valeurs d'une colonne

Bsr,
Est-il possible de simplifier ces 2 requête pour obtenir la différence entre elles dans une cellule "delta" ?

Code:

---

1 2 3

SELECT maires_nb FROM nbr_maires WHERE id = (SELECT MAX(id) FROM nbr_maires); SELECT maires_nb FROM nbr_maires WHERE id = (SELECT MAX(id) -1 FROM nbr_maires);

---

Code:

---

SELECT maires_nb FROM nbr_maires WHERE id > (SELECT MAX(id)-2 FROM nbr_maires);

---

Code:

---

1 2 3 4 5 6

SELECT (SELECT maires_nb FROM nbr_maires WHERE id = (SELECT MAX(id) FROM nbr_maires)) - (SELECT maires_nb FROM nbr_maires WHERE id = (SELECT MAX(id) -1 FROM nbr_maires)) AS delta ;

---

Mais le procédé est très mauvais, on ne peut pas faire sereinement des opérations comme MAX(id) - 1, ça n'a pas de sens.

Donne-nous plutôt le schéma de ta table, un échantillon de données, et le résultat que tu veux en sortir.

Bsr,

Merci à vous 2 pour vos propositions.
Ma demande était en effet "impossible".

J'ai opté pour bcp plus simple

Code:

---

SELECT id FROM nbr_maires ORDER BY id DESC LIMIT 1

---

ce qui me permet de trouver les données de

Code:

---

id

---

et de

Code:

---

id - 1

---

simplement dans mes requêtes.

Le principal ennui, ici, est que tu ne peux pas être certain qu'une entrée identifiée par « max(id) - 1 » existe forcément si ladite entrée a été supprimée avant ton appel.

Si tu t'autorises SQL:2003 (plus de vingt ans tout de même), tu peux en revanche utiliser les fonctions OLAP, avec lesquelles ont été notamment introduites les fonctions ROW() et RANK() : https://sqlpro.developpez.com/articl...clause-window/

ROW() te permet alors de demander directement au SGBD de produire un numéro de ligne, sur laquelle tu peux ensuite poser un filtre, en ne récupérant que les lignes où ROW() est inférieur ou égal à 2.

Non seulement on n'est pas certain qu'il existe une ligne portant l'identifiant de valeur max(id) - 1, mais, si l'identifiant est calculé par le SGBD (identity, counter, auto_increment...) on n'est pas non plus certain que l'identifiant dont la valeur est la plus forte est celui le plus récent !
Il faut rappeler que dans un environnement multi utilisateurs et multi threads, la distribution des valeurs d'identifiants attribuées par le SGBD n'est pas séquentielle : elle se fait le plus souvent par paquets à chaque thread ayant des insertions à traiter.
Par exemple, un thread 1 reçoit du moteur du SGBD les valeurs d'id 100 à 109 pour son prochain lot d'insertions alors qu'un autre thread 2 reçoit les valeurs d'id 110 à 119 (cas de lots de 10 id).
Mais rien n'interdit que ce soit le 2e thread qui commite le premier tout ou partie des identifiants qu'il a reçus, auquel cas l'identifiant 115 du thread 2, par exemple, sera commité AVANT l'identifiant 108 du thread 1.
Il va sans dire que tout ou partie des identifiants reçus peut ne pas être commité, d'où les "trous" de numérotation.

Il ne faut jamais utiliser une valeur d'identifiant attribuée par le SGBD pour un usage fonctionnel. Si l'on a besoin d'une chronologie de création, il faut disposer d'un horodatage fin (ie timestamp) de création de la ligne.

re,

Pas bien compris le besoin, ni les données initiales

Est-ce que :

Code:

---

1 2 3 4 5 6

SELECT id ,maires_nb ,lag(id) over (order by id) as id_prec ,lag(maires_nb) over (order by id) as maires_nb_prec FROM nbr_maires order by id desc

---

Va dans le "bon" sens ?

Citation:

---

Envoyé par Michel.Priori

Est-ce que [. . .]
Va dans le "bon" sens ?

---

Il n'y a pas de bon sens quand on utilise un identifiant technique comme critère fonctionnel et en particulier, comme très souvent, pour tenter - en vain - d'en déduire une chronologie.

Cf. ma réponse précédente.