Trouver les trous dans des périodes sur la même table

Bonjour.

J'ai un problème qui ressemble à celui-ci.

Je dois trouver les trous dans la continuité temporelle entre les différentes lignes d'une table, sur la même colonne.

Structure simplifiée de la table 'detentions' :
- B_D_FK_IND_BOVINS : l'identifiant du bovin
- B_D_DAT_ENTR : la date d'entrée dans une exploitation, de type DATE
- B_D_DAT_SORT : la date de sortie de l'exploitation, de type DATE

Normalement, les différentes détentions d'un bovins devraient se suivre avec au maximum 1 jour entre la date de sortie d'une détention et la date d'entrée de la détention suivante.

On cherche à compter le nombre de bovins pour lesquels il y a des trous entre les dates de sortie et les dates d'entrée de la détention suivante.

J'ai fait la requête suivante qui me donne un résultat mais je ne suis pas sûr de moi sur ce coup :? :

Code:

---

1 2 3 4 5 6 7 8 9

SELECT COUNT(DISTINCT d1.B_D_FK_IND_BOVINS) AS NbBovins FROM bdni2.detentions d1 WHERE DATEDIFF( (SELECT d2.B_D_DAT_ENTR FROM bdni2.detentions d2 WHERE d2.B_D_FK_IND_BOVINS = d1.B_D_FK_IND_BOVINS AND d2.B_D_DAT_ENTR > d1.B_D_DAT_ENTR ORDER BY d2.B_D_DAT_ENTR LIMIT 1), d1.B_D_DAT_SORT) > 1

---

Ca vous semble bon ?

Oui, si MySQL accepte le ORDER BY et le LIMIT dans la sous-requête.
A force de "jouer" avec plusieurs SGBD, je finis par ne plus savoir lesquels acceptent quoi et lesquels refusent...

ced

Saluton,
Toujours la même inquiétude, Cinéphil, comment MySQL va-t'il digérer cette sous-requête corrélée ?
Peut-être

Code:

---

1 2 3 4

LEFT JOIN bdni2.detentions d2 ON d2.B_D_FK_IND_BOVINS = d1.B_D_FK_IND_BOVINS AND d2.B_D_DAT_ENTR=DATE_ADD(d1.B_D_DAT_SORT, INTERVAL 1 DAY) WHERE d2.B_D_DAT_ENTR IS NULL

---

Comme j'ai dit :

Citation:

---

la requête suivante qui me donne un résultat

---

Ma question était plutôt sur la logique de la requête.
Le résultat ne semble a priori pas incohérent mais difficile à vérifier sur 42 millions de lignes de détention !

Citation:

---

Envoyé par CinePhil

Ma question était plutôt sur la logique de la requête.
Le résultat ne semble a priori pas incohérent mais difficile à vérifier sur 42 millions de lignes de détention !

---

C'est bien parce que la logique m'apparaît cohérente que j'ai cherché à te proposer une solution équivalente contournant la sous-requête corrélée ce que MySQL appréciera d'autant plus qu'il s'agit de 42 millions de lignes.

Si la logique est bonne alors ça va. Ce n'est pas une requête que j'ai besoin d'exécuter régulièrement et le temps de réponse n'est pas si catastrophique que ça.

Merci.