Arret Commande SQL dès un élément trouvé

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:

---

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

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 ?

Merci pour votre réponse

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

Code:

---

SELECT ID FROM matable WHERE ......

---

et tester la fin de fichier derrière.

en fait, je cherche un equivalent a LIMIT du mysql

cordialement

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:

---

1 2 3 4 5 6 7

SELECT 1 FROM DUMMY WHERE EXISTS ( SELECT 1 FROM matable WHERE condition );

---

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:

---

Select FIRST Monchamp from Matable

---

Mais ce mot clé est inconnu

Cordialement

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 ?

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

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

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

Code:

---

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:

---

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:

---

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

---

Et rectifiez votre requête comme suit :

Code:

---

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 +

et un

Code:

---

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

---

ne fonctionne pas non plus ??

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.

Citation:

---

Envoyé par obione

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 :aie:.

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

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

Code:

---

select id from matable where monchamp=4

---

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

Code:

---

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

---

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