Discussion :

[obione]

Bonjour,

Je lance une commande SQL dont le résultat peut être assez long a s'afficher.
Or, je me sers de cette commande uniquement pour vérifier l'existence d'au moins un élément. Actuellement, je fais un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Select count (ID) from matable where ......
avec pas mal de jointure a la suite

Je me fous qu'il y ai un, deux ... ou 10 millions enregitrments retournés

Existe t-il en SQL des mots clés ... permettant de stopper le recherche dès le premier élément trouvé ?

Merci

[al1_24]

SQL est un langage de traitement ensembliste de données.
Le SGBD recherchera donc toutes les données correspondant au filtre de la requête.
D'autant plus avec COUNT : la valeur retournée est le nombre d'enregistrements trouvés.
Comment retourner ce nombre si la recherche n'est pas terminée ?

[obione]

Merci pour votre réponse

Je met count, ainsi il me renvoie une seul ligne
j'aurais très bien utilisé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT ID FROM matable WHERE ......

et tester la fin de fichier derrière.

en fait, je cherche un equivalent a LIMIT du mysql

cordialement

[al1_24]

Si ton SGBD (que tu n'as pas précisé : Règles du forum Langage SQL à lire par tous) comporte un optimiseur extrêmement efficace, il tirera peut-être parti de cette construction, qui retournera 0 ou 1 ligne suivant que le critère est vérifié ou non :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT 1
FROM DUMMY
WHERE EXISTS
 ( SELECT 1
   FROM matable
   WHERE condition
 );

[obione]

1000 excuses, c'est vrai, j'utilises firebird 1.5

Apparament, votre méthode est inefficace sous firbird, c'est dommage. En cherchant un peu j'ai croisé des mots clés, comme FIRST, tel que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select FIRST Monchamp from Matable

Mais ce mot clé est inconnu

Cordialement

[al1_24]

Des clauses de limitation des résultats, telles que FIRST, TOP ou LIMIT, s'appuient sur un ensemble de lignes ordonné.
Et pour pouvoir ordonner les lignes résultant d'une requête... il faut les avoir toutes récupérées. En effet, comment prédire que la dernière ligne trouvée correspondant au filtre ne sera pas la première une fois appliquée la clause ORDER BY ?

[obione]

Exact, j'étais justement en train de m'en rendre compte !

[al1_24]

C'est peut-être la partie condition de la requête qui est à optimiser...
Penser aussi au niveau physique : index, statistiques...

[obione]

En fait, c'est plutot les jointures sur de grosses tables (sur lesquelles je fait des sélections) qui ralentisse la requête.

Mais bon, je vais chercher.

Merci

[SQLpro]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT 1 -- ou tout autre chose
WHERE  EXIST(SELECT *
             FROM   --> la suite étant votre requête originale
            )

Si votre SGBDR est Oracle, rectifiez comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT 1 -- ou tout autre chose
FROM   DUAL
WHERE  EXIST(SELECT *
             FROM   --> la suite étant votre requête originale
            )

Si votre SGBDR ne supporte pas de requête select sans la clause FROM alors ajoutez une table quelconque d'une seule ligne, par exemple ;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
CREATE TABLE T1 (C INT);
INSERT INTO T1 VALUES (1);

Et rectifiez votre requête comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT 1 -- ou tout autre chose
FROM   T1
WHERE  EXIST(SELECT *
             FROM   --> la suite étant votre requête originale
            )

A +

[Yanika_bzh]

et un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT FIRST 1 * FROM .......

ne fonctionne pas non plus ??

[obione]

Merci pour vos réponse.

Concernat le select 1 ... where exists ..., firebird attend toujours la fin de la requête de recherche, je ne comprend pas pourquoi et je cherche...

Le Select first 1 est obligé de lire l'ensemble des réponses pour envoyer effectivement le premier et ce, malgré l'absence de clause ORDER BY

Si je ne trouve pas, je découperai ma commande SQL en plusieurs 'morceau' : pour un eneg donné de ma table, j'irai chercher si des enreg corresponde et dès que j'en trouve un, j'arrête.

Statistiquement, par rapport aux élements de ma BDD, en lisant par ordre chronologique, ce sera en général plus rapide.

[Antoun]

Si je ne trouve pas, je découperai ma commande SQL en plusieurs 'morceau' : pour un eneg donné de ma table, j'irai chercher si des enreg corresponde et dès que j'en trouve un, j'arrête.

Statistiquement, par rapport aux élements de ma BDD, en lisant par ordre chronologique, ce sera en général plus rapide.

Non. Comme l'a souligné Alain, les SGBD ont un fonctionnement ensembliste et non procédural. C'est-à-dire qu'ils sont optimisés pour traiter des données en masse et non ligne à ligne. Autrement dit, lire les ligne une par une revient à prendre l'autoroute en restant bloqué en première vitesse... on finit par arriver au bout (généralement), mais ce n'est pas la méthode la plus rapide .

Pour accélérer ta requête, je suggèrerais de poser un petit index sur la ou les colonnes du WHERE.

[obione]

Ce que je voulais dire, c'est que je vais lire un enreg de ma table principal,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select id from matable where monchamp=4

sans jointure, avec des sélections minimale et, par une autre requête,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select blabla from uneautre table join etc ..... where champclétrangere=%d

, vérifier si des enreg existent sur les autres tables jointes.