Nombre maximal de valeurs passées dans l'instruction IN / NOT IN

[kamnouz]

Bonjour à tous ,

Quelqu'un pourrait-il me dire combien peut-on passer au maximum de valeur dans l'instruction IN / NOT IN ?

Merci d'avance pour votre aide.

[ORA-007]

1000 il me semble.

Au delà il faut decouper :

Code :

1
2
3
4
5
6
7
8
9
 
WHERE .... IN 
(
...,
...
) OR .... IN 
(
....
)

[dehorter olivier]

Cela devrait être une caractéristique propre à chaque SGBD, non ?

[kamnouz]

Merci pour vos réponses !

En faite voici ma requetes :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
SELECT  ALL       T02.E7B8ZC,T01.CXAN8X,T01.CXHZZE,T01.CXB9ZC,T03.NUGUFX,T03.NUGVFX,T02.E7BUZA,T04.DYEVZE,T03.NUDWF7,T03.NUG3FX,T03.NUG4FX,T03.NUDXF7,T01.CXB6ZA,T01.CXA3ZB,T01.CXARZF,T01.CXCEZA,T02.E7BUZA                FROM DISACTDTA1.COE7REP T02,                                     DISACTDTA1.COCXREP T01,                                          
SATACTDTA1.FINURED T03,                                          
DISACTDTA1.CODYREP T04,                                          
SATACTDTA1.FAFLRED T05,                                          
DISACTDTA1.COC1REP T06                                            
												WHERE     E7B8ZC = CXB8ZC                                                  
AND     NUB8ZC = CXB8ZC                                                  
AND     DYBUZA = E7BUZA                                                  
AND     NUGVFX = FLAAFJ                                                  
AND     E7CIZA = DYCIZA                    
AND     T01.CXCEZA = T06.C1CEZA  
AND     T01.CXCDZA IN('" . implode("','", $_SESSION['code_groupe']) . "') 
AND     T02.E7B8ZC  IN('" . implode("','", $abonnes) . "') 
AND     T02.E7BUZA IN('" . implode("','", $_POST['CHECK']) . "')
AND     CXA3ZB <> 0                        
AND     CXA6ZB = 0  
GROUP BY E7B8ZC,E7BUZA,CXHZZE,CXB9ZC,NUGUFX,NUGVFX,DYEVZE,CXAN8X,NUDWF7,NUG3FX,NUG4FX,NUDXF7,CXB6ZA,CXA3ZB,CXARZF,CXCEZA,E7BUZA

L'instruction suivante:

Code :

1
2
 
AND     T02.E7B8ZC  IN('" . implode("','", $abonnes) . "')

est un tableau qui peut contenir jusqu’à 80 000 valeurs , combien puis-je faire le découpage ?

[StringBuilder]

Vu la volumétrie, personnellement, je passerais par une jointure sur une table temporaire : plus de problème de nombre de IN, et certainement de meilleures performances au final.

[kamnouz]

Merci de ta réponse !!

Peux-tu me faire voir la structure du query avec une table temporaire stp ? parce que je ne visualise pas très bien ce que tu veux dire

[StringBuilder]

Parmi les syntaxes possibles, la plus simple.

au lieu de faire :

Code :

1
2
3
4
 
...
AND CHAMP IN (...)
...

tu fais :

Code :

1
2
3
4
 
...
AND EXISTS (SELECT NULL FROM TABLE_TEMPORAIRE t WHERE CHAMP = t.champ)
...

Ca devrait être plus performant, surtout si tu utilises plusieurs fois de suite les mêmes listes de valeurs (donc réutilisation de la table temporaire plutôt qu'une liste à n'en plus finir de valeurs dans un IN)

[kamnouz]

Ok super je test ça tout de suite
Merci

[SQLpro]

Envoyé par kamnouz

Bonjour à tous ,

Quelqu'un pourrait-il me dire combien peut-on passer au maximum de valeur dans l'instruction IN / NOT IN ?

Merci d'avance pour votre aide.

Il n'y a théoriquement aucune limite d'aucune sorte prévue par le langage (norme).

Cependant et comme on vous l'a indiqué, plus il y en a, moins c'est optimal.

Donc, passez par une table pour stocker préalablement vos éléments.

A +

[dehorter olivier]

ok avec stringBuilder sur l'utilisation d'une table temporaire

avec cette syntaxe plutôt que EXISTS

Code :

1
2
3
 
FROM TABLE
    INNER JOIN Table_Temp (Table_Temp.id = TABLE.Id)

plus efficace que le EXISTS


Et ce serait bien de suivre la norme pour les jointure

[CinePhil]

Quelque chose me dit que $_SESSION['code_groupe'] et $abonnes contiennent des données qui ont été extraites de la BDD...
Pourquoi utiliser une table temporaire si les données existent déjà en BDD ?

[StringBuilder]

Envoyé par dehorter olivier

ok avec stringBuilder sur l'utilisation d'une table temporaire

avec cette syntaxe plutôt que EXISTS

Code :

plus efficace que le EXISTS


Et ce serait bien de suivre la norme pour les jointure

Hmmmm, en effet, au départ, j'avais pensé à la bête jointure (cf. mon premier post) mais pour je ne sais quelle obscure raison, tout d'un coup je me suis dis que c'était pas possible

On va remettre ça sur le fait que je suis jeune papa, et que ça fait 15 jours que je ne sais plus ce que ça veut dire le mot "dormir"

[Rei Ichido]

Envoyé par dehorter olivier

ok avec stringBuilder sur l'utilisation d'une table temporaire

avec cette syntaxe plutôt que EXISTS

Code :

plus efficace que le EXISTS

Sur l'efficacité comparative, c'est discutable et ça dépend du SGBD. Cela peut aussi poser des problèmes de dédoublement de lignes si la table temporaire a des lignes en double ...

[dehorter olivier]

Envoyé par Rei Ichido

Sur l'efficacité comparative, c'est discutable et ça dépend du SGBD. Cela peut aussi poser des problèmes de dédoublement de lignes si la table temporaire a des lignes en double ...

Bien sur, mais l'utilisation d'une table temporaire doit être "conceptualisée" pour répondre aux besoins et tester son efficacité par rapport à une requête plus "classique" dans sa construction

[Yanika_bzh]

Envoyé par dehorter olivier

avec cette syntaxe plutôt que EXISTS

Code :

plus efficace que le EXISTS

Les deux syntaxes n'ont pas la meme signification. La jointure ne répond pas strictement aux specs decrites...
[/QUOTE]

Et ce serait bien de suivre la norme pour les jointure

Je suppose que vous voulez parler des jointures explicites décrites dans la grammaire BNF SQL-92 ? Or cette meme grammaire decrit aussi bien la jointure implicite... La norme n'est donc pas définie dans cette grammaire, mais dans votre propre méthode de conception. Si il est effectivement conseillé de l'utiliser, elle n'est pas LA norme ...

@kamnouz
Dans la requete initiale, ce qui me choque c'est le group by, sans utilisation de fonction d'aggrégation... Je pense que cela est fait pour palier une erreur de clause et gerer la génération de doublons.
L'utilisation de la jointure explicite peut plus facilement vous ammener a trouver la cause de ces doublons...

Comme précaunisé par les intervenants principaux, utilisez une table temporaire, indexez vos colonnes pour optimiser vos performances de recherche, utilisez le EXISTS, et recherchez la cause de la necessité de votre GROUP BY.

Bon Courage

[iberserk]

Je suppose que vous êtes sous MySQL (question non posée je crois...)?

Vous générez donc votre IN côté client au moment de générer votre requêtes?
Cette génération fait'elle appel à un mécanisme métier ou est-ce une liste issue de l'IHM (multi-sélection dans une grille par exemple)?

Si c'est le premier cas je vous encourage à déporter ce métier dans votre code SQL afin de remplacer le IN par des jointures ou filtres...