Sur le site SQL Pro
Nous avons lu ceci :
le tri est un tri interne, il ne faut donc placer dans cette clause que les
noms des colonnes présentées dans la clause SELECT
Actuellement nous utilisons des requète avec dans l' "order by " des
colonnes qui ne sont pas dans le select (pour éviter a charge réseau)
Quelles incidences porter à ce code ? est ce une question de lenteur ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
bonjour,
Gilles a écrit:
Bonjour à tous,
Sur le site SQL Pro Nous avons lu ceci : le tri est un tri interne, il ne faut donc placer dans cette clause que les noms des colonnes présentées dans la clause SELECT
ça c'est la norme. SQL Server comme d'autres SGBDR peuvent faire du tri externe
Actuellement nous utilisons des requète avec dans l' "order by " des colonnes qui ne sont pas dans le select (pour éviter a charge réseau)
Quelles incidences porter à ce code ? est ce une question de lenteur ?
un tri est toujours un processus couteux. Le tri externe un peu plus que le tri interne.
Merci de vos réponses ...
Gilles SQL server
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
bonjour,
Gilles a écrit:
Bonjour à tous,
Sur le site SQL Pro
Nous avons lu ceci :
le tri est un tri interne, il ne faut donc placer dans cette clause que les
noms des colonnes présentées dans la clause SELECT
ça c'est la norme. SQL Server comme d'autres SGBDR peuvent faire du tri externe
Actuellement nous utilisons des requète avec dans l' "order by " des
colonnes qui ne sont pas dans le select (pour éviter a charge réseau)
Quelles incidences porter à ce code ? est ce une question de lenteur ?
un tri est toujours un processus couteux. Le tri externe un peu plus que le tri
interne.
Merci de vos réponses ...
Gilles
SQL server
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Sur le site SQL Pro Nous avons lu ceci : le tri est un tri interne, il ne faut donc placer dans cette clause que les noms des colonnes présentées dans la clause SELECT
ça c'est la norme. SQL Server comme d'autres SGBDR peuvent faire du tri externe
Actuellement nous utilisons des requète avec dans l' "order by " des colonnes qui ne sont pas dans le select (pour éviter a charge réseau)
Quelles incidences porter à ce code ? est ce une question de lenteur ?
un tri est toujours un processus couteux. Le tri externe un peu plus que le tri interne.
Merci de vos réponses ...
Gilles SQL server
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Med Bouchenafa
Je ne sais pas comment se débrouille les autres SGBDR mais SQL Server traite le ORDER BY de la même manière que l'argument soit inclus ou pas dans la clause SELECT. Que tu ramènes ou pas la colonne dans le SELECT, Il n'y absolument aucune dégradation de performance entre les deux. Il est aisé de le vérifier en analysant les plans de requêtes de deux instructions SELECT portant sur une table de bonne volumétrie. Mieux encore, ce que tu fais est très intelligent. Tu ne ramènes que les colonnes qui t'intéressent et donc tu satures moins le réseau et tu libères plus vite les buffers de SQL Server. C'est ce qu'il faut continuer à faire dans la mesure du possible.
-- Bien cordialement Med Bouchenafa
"Gilles" a écrit dans le message de news: #we2bfT$
Bonjour à tous,
Sur le site SQL Pro Nous avons lu ceci : le tri est un tri interne, il ne faut donc placer dans cette clause que les noms des colonnes présentées dans la clause SELECT
Actuellement nous utilisons des requète avec dans l' "order by " des colonnes qui ne sont pas dans le select (pour éviter a charge réseau)
Quelles incidences porter à ce code ? est ce une question de lenteur ?
Merci de vos réponses ...
Gilles SQL server
Je ne sais pas comment se débrouille les autres SGBDR mais SQL Server traite le ORDER BY de la même
manière que l'argument soit inclus ou pas dans la clause SELECT.
Que tu ramènes ou pas la colonne dans le SELECT, Il n'y absolument aucune dégradation de performance
entre les deux.
Il est aisé de le vérifier en analysant les plans de requêtes de deux instructions SELECT portant
sur une table de bonne volumétrie.
Mieux encore, ce que tu fais est très intelligent. Tu ne ramènes que les colonnes qui t'intéressent
et donc tu satures moins le réseau et tu libères plus vite les buffers de SQL Server.
C'est ce qu'il faut continuer à faire dans la mesure du possible.
--
Bien cordialement
Med Bouchenafa
"Gilles" <glebarbier@supprimerceci_segilog.com> a écrit dans le message de news:
#we2bfT$EHA.3120@TK2MSFTNGP12.phx.gbl...
Bonjour à tous,
Sur le site SQL Pro
Nous avons lu ceci :
le tri est un tri interne, il ne faut donc placer dans cette clause que les
noms des colonnes présentées dans la clause SELECT
Actuellement nous utilisons des requète avec dans l' "order by " des
colonnes qui ne sont pas dans le select (pour éviter a charge réseau)
Quelles incidences porter à ce code ? est ce une question de lenteur ?
Je ne sais pas comment se débrouille les autres SGBDR mais SQL Server traite le ORDER BY de la même manière que l'argument soit inclus ou pas dans la clause SELECT. Que tu ramènes ou pas la colonne dans le SELECT, Il n'y absolument aucune dégradation de performance entre les deux. Il est aisé de le vérifier en analysant les plans de requêtes de deux instructions SELECT portant sur une table de bonne volumétrie. Mieux encore, ce que tu fais est très intelligent. Tu ne ramènes que les colonnes qui t'intéressent et donc tu satures moins le réseau et tu libères plus vite les buffers de SQL Server. C'est ce qu'il faut continuer à faire dans la mesure du possible.
-- Bien cordialement Med Bouchenafa
"Gilles" a écrit dans le message de news: #we2bfT$
Bonjour à tous,
Sur le site SQL Pro Nous avons lu ceci : le tri est un tri interne, il ne faut donc placer dans cette clause que les noms des colonnes présentées dans la clause SELECT
Actuellement nous utilisons des requète avec dans l' "order by " des colonnes qui ne sont pas dans le select (pour éviter a charge réseau)
Quelles incidences porter à ce code ? est ce une question de lenteur ?
