Discussion :

[clavier12AZQSWX]

bonjour,

j'ai une table toute simple :
id_mission
id_personne
date : date
debut : time
fin : time

j'aimerai savoir si il y a un moyen en sql (car là je fais en itératif sur le serveur avec une boucle lourde) de trouver les id_mission qui sont en date croisée (missions superposées).

par exemple, toto qui a une mission le 1/8/2012 de 8h à 11h et une autre le même jour de 8h à 9h (ce qui est impossible physiquement).

mon contenue de table serait :
mission personne date debut fin
1 1 20130801 08 09
2 1 20130801 8 11
3 1 20130802 8 11

il faudrait que la requête me ressorte l'id mission 1 (ou 2)

Je suis certains que c'est une question que quelqu'un s'est déjà posé, ça me semble être un cas d'école pourtant je ne trouve pas de requête tordue qui puisse faire ça sans passer par une itération.

Je crois (après avoir pensé et essayé moultes solutions en vain) que je dois mixer l'operateur ANY avec une condition à base de OVERLAPS mais pas moyen de sortir un truc qui fonctionne...

quelqu'un a-t-il une idée ?


ps : désolé de sortir un tel casse-tête chinois un jour de vacance, mais je travaille !

[punkoff]

bonjour,

quelle requête avez vous essayez ?

Un simple test d'existante (EXISTS) devrait venir à bout de ceci.

[SQLpro]

Il serait beaucoup plus intéressant de mettre une contrainte CHECK qui empêcherait une telle saisie plutôt que de faire des tests à postériori.

A me lire :
http://blog.developpez.com/sqlpro/p9...recouvrement_p
http://blog.developpez.com/sqlpro/p9...es_externe_ave

A +

[estofilo]

L'idée qui doit manquer est de joindre la table à elle-même.
Les conditions de jointure seraient:
Même personne
ET numéros de mission différents
ET OVERLAPS positif entre les intervalles de temps de chaque côté de la jointure.

[tse_jc]

Bonjour,

Je suis de l'avis de SQLpro à passer par une contrainte check.

Pourquoi? Tout simplement car il ne faut pas perdre de vue le rôle essentiel du SGBDR dans votre application : S'assurer de préserver non seulement l'acidité de vos données mais également leur qualité. Or effectuer un contrôle a postériori, signifie permettre l'enregistrement de données non conformes à vos contraintes métier.
S'assurer de cela devrait être votre première priorité.

Il n'est déjà pas forcément évident de gérer et de requêter des données valides à 100% au quotidien dans un contexte optimisé, pour en plus devoir s'imposer l'écriture de requêtes dédiées à l'extraction de données conformes préalablement à tous vos traitements habituels.

Ensuite si vous voulez vous amuser à faire du bricolage ou à créer de la volumétrie "poubelle" dans votre BD pour l'exercice, libre à vous, mais bon vous savez ce que j'en pense maintenant.

Cordialement,

Jc.

[clavier12AZQSWX]

je comprends votre point de vue sur les contraintes seulement le cas que je cherche n'arrive que peut-être 5% des cas. donc pourquoi imputer à tout le monde un traitement qui sera long et aura un impact dans la réactivité de l'outil au moment où ça arrive....