Requete requête sous sybase

[eddie]

Bonjour,

J'ai un petit problème de sous requète sous Sybase
Je sais que l'on peux appliquer après un FROM une sous requête en SQL du type

Code :

1
2
3
4
 
SELECT A.valeur,A.count 
FROM (SELECT nom,count(*) AS "count" FROM TABLE GROUP BY nom) A
WHERE A.count<10

où la table est remplacée par une sous requète.
Je n'arrive pas à appliquer cette méthode à une requète Sybase, et ca m'arrangerai bien

Sachant que les views ne m'interrèssent pas ...

Merci d'avance

[fadace]

Sous Sybase, les sous-requêtes marchent, mais elles ne sont pas à mettre n'importe où, comme par exemple dans ton exemple.

Par contre, il est souvent plus judicieux de passer pour une jointure simple, ce qui est plus optimal dans la plupart des cas.

Pour ton exemple, si tu veux n'afficher que les noms apparaissant plus de 10 fois, tu doix utiliser un having si tu pose une condition sur le résultat d'un agrégat

Code :

1
2
3
4
5
 
SELECT Nom, count(*) 
FROM maTable 
GROUP BY Nom 
HAVING count(*) > 10

Par contre, tu peux faire des sous-requêtes de type

Code :

1
2
3
4
 
SELECT nom, age 
FROM maTable 
WHERE age IN (SELECT max(age) FROM mesClient)

... mais c'est beaucoup + futé d'écrire

Code :

1
2
3
4
 
SELECT nom , max(mesClients.age)
FROM maTable, mesClients
WHERE maTable.age = mesClients.Age

[Zeo_BO]

PAs trop d'accord dans le sens ou où du SQL ne s'optimise pas, ce sont l'utilisation judicieuse des index ou cluster qui vont permettre uen bonne performance.
Donc tu peux tout à fait Générer dans ta clause Where un filtre de sous requête, mais n'oublis pas que si tu à toujours un risque de générer un produit cartésien dans ta sous-requête.
A toi de connaitre précisement ton MCD.
Je te conseillerai d'utiliser le Sp_helpindex pour déterminer les index disponible, de modéliser tes jeux de requetes qui devrait créer tes tables en clause WHERE dans ta requête finale.
En effet je doute que cette question provienne de la simple méconnaissance des agrégats.
Quoiqu'il arrive, je te conseille avant toute chose de mettre dans ton script avant l'éxecution un :
set noexec on
go
set showplan on
go
PS : table scan en resultat, c mauvais signe.
Positioning by key, c mieux
Using clustered index, c good.
JE te joins un exemple concret de requete sybase avec une sous requete :

select convert(char(12),C.adtvl,103),";",
convert(char(6),B.azcogl1),";",
"EUR",";",
str(C.amtvlnr,10,3),";",
str(C.amtactr,10,3)
from ADMIN..aprt A,ADMIN..aptx B(index aptx_c),ADMIN..ahvl C(index ahvl_nc2)
where C.aidprt=A.aidprt
and B.aidptx=A.aidprt
and B.azcogl1 like "508%"
and C.adtvl between (select all max(C.adtvl) from ADMIN..ahvl C where C.aidprt="
5000001") and getdate()

J'espére que cet exemple concret t'apportera une vraie réponse.
3 tables sur 1 base sont exploitées.
La contrainte majeure est que l'élément de tri n'est pas un index ou un élément de clef.
Cependant, un des éléments de requête est une partie de clef décomposée.
Malheureusement, un tri doit être opéré dessus.
Heureusement, elle dispose d'un index qui est lui déclarable.
Et là, ma requête, qui peut être écrite plus simplement est réellement opérationnelle puisqu'elle génére mon résultat en un minimum de temps de traitement.



EOF

[fadace]

Envoyé par Zeo_BO

PAs trop d'accord dans le sens ou où du SQL ne s'optimise pas, ce sont l'utilisation judicieuse des index ou cluster qui vont permettre uen bonne performance.

Si, la façon d'écrire le code s'optimise !

Exemple ?

Code :

1
2
3
SELECT ID, Valeur 
FROM Comptes
WHERE Valeur * 1.2 < 100

va générer un Table Scan sur la table Comptes, même si un index existe sur Valeur.

par contre

Code :

1
2
3
SELECT ID, Valeur 
FROM Comptes
WHERE Valeur < 100/1.2

pourra utiliser la SARG, et donc l'index sur Valeur

CQFD

Envoyé par Zeo_BO

set noexec on
go
set showplan on
go

Il vaut mieux exécuter ces 2 sets dans l'ordre inverse : le noexec on risque de rendre inopérant le showplan

Se plus, si tu veux obtenir encore plus d'info de l'optimiseur, tu peux exécuter

Code :

1
2
3
dbcc traceon(3604)
dbcc traceon(302)
dbcc traceon(310)

... mais là, ça devient alors très, très verbeux...