Salut,
 
Petit problème, même pour le titre je galère, du coup je vais vous donner un exemple.
J'ai une table constituée de 2 colonnes : ID et DATA
ID est numérique, DATA est un varchar.
 
Les données d'exemple sont les suivantes :  
 
ID   -   DATA
1    -   A
1    -   B
1    -   C
2    -   D
2    -   E
2    -   F
3    -   G
4    -   A
4    -   D
4    -   H
5    -   C
5    -   I
5    -   J
6    -   D
7    -   H
7    -   J
 
Mon objectif est de mettre à jour l'ID avec la valeur d'ID la plus grande qui ne contient pas de DATA de l'ID. Par exemple, dans ce cas, l'ID 1 contient A, B, C. Le premier ID qui contient soit A, soit B soit C est l'ID 4, du coup cela signifie que je peux remplacer 1 par 3 et 2 par 3.
De la même façon, je peux remplacer 4 par 5 puisqu'il n'y a pas de données communes entre les ID 4 et 5, idem pour 6 et 7.
(dans la réalité, les ID ne se suivent pas forcément, il peut y avoir des sauts)
 
Aujourd'hui, j'ai cette requête :  
 

 
ce qui revient, pour chaque ligne, à trouver le plus grand ID qui précède le plus petit ID qui contient une DATA commune.
 
Je dois donc faire un curseur, trouver le max inférieur au min commun, mettre à jour, recréer le curseur à partir du min supérieur au dernier max trouvé etc., et la requête n'est pas super performante puisqu'elle parcourt plusieurs fois la table.
 
Je veux aussi garantir l'ordre d'intégration, c'est à dire que je pourrais détecter les ID 1, 2, 3 et 7 comme n'ayant pas de DATA commune, mais comme 4 et 5 ont des données portées par 7, je ne veux pas remplacer 1, 2 et 3 par 7.
 
Je n'ai pas trouvé de moyen de faire le traitement en une seule fois, je ne vois pas trop de mots clés qui pourraient m'aider.
 
Merci,
 
 
 
 

Y'a moyen de savoir exactement à quoi correspondent ces données (ID et data), svp ? Parce que ta difficulté vient peut-être d'un pb de modélisation des données dans la BD
 
Perso, j'ai du mal à comprendre la raison de ce traitement : pourquoi tu dois le faire a posteriori et pourquoi c'est pas fait au moment de la saisie/import ?

J'ai vu ton MP. Aujourd'hui, avec le big data, les entreprises ont tendance à conserver toutes leurs data, qu'elles soient structurées ou pas, "au cas où". Avec des BD NoSQL, c'est pas un problème. En effet, avec l'avancée des algos, les entreprises ne savent pas forcément déterminer a priori de quelles données elles vont avoir besoin pour réaliser tel ou tel traitement
 
Avant, avec les SGBDR, on ne gardait que les données qui servaient à faire un traitement clairement identifié (ou plusieurs traitements identifiés). Et dans ce cas, on structurait la BD pour permettre ce ou ces traitements.
 
Si tu cherches du ROI sur l'exploitation de données, je te recommande de lire quelques livres sur le big data et NoSQL Dans la collection Eyrolles, il y en a de très bons.
https://www.amazon.fr/bases-données [...] 00WTGK4HC/
https://www.amazon.fr/Data-science- [...] 212142439/