Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

optimiser une requete qui doit de toute façon lire toute la base

48 réponses
Avatar
WebShaker
salut.

on me demande de réaliser une requête qui consiste a compter le nombre
de produit vendu par référence.

il s'agit donc de
SELECT ref, count(*) FROM commandline GROUP BY ref;

mais j'ai 17.000.000 de lignes de de commandes dans ma base...
Alors la question est simple.
que peut on faire pour optimiser ce genre de requête...

surtout que le requête suivante est de compter le quantité par catégorie
de produit.
la ca donne

SELECT cat, count(*) FROM commandline INNER JOIN produit ON
commandline.idproduit = produit.idproduit GROUP BY cat;

Les suivantes sont encore pire...
Dans touts les cas, il me faut parcourir la table commandline.
ou alors il faut que je fasse un mécanisme de cache, mais la je ne
connais pas trop les techniques (table temporaire peut être, je ne sais
pas).

Etienne

10 réponses

1 2 3 4 5
Avatar
helios
Alain Montfranc a écrit :
helios a présenté l'énoncé suivant :
rien en fait



sai marant lah plu groce baze de donnai komerssialeux aux monde ait...
chez FT et... sou Oracle !




la plus grosse base commercial n'est pas sous oracle ni pick mais sur
papier et cela s'appelle l'ancien testament

repris dans la thora la bible et referencer dans le coran
Avatar
Alain Montfranc
Il se trouve que helios a formulé :
Alain Montfranc a écrit :
helios a présenté l'énoncé suivant :
rien en fait



sai marant lah plu groce baze de donnai komerssialeux aux monde ait... chez
FT et... sou Oracle !




la plus grosse base commercial n'est pas sous oracle ni pick mais sur papier
et cela s'appelle l'ancien testament

repris dans la thora la bible et referencer dans le coran



ah nons sait tou kopé surre les bookins de Ron Hubard.
Avatar
JKB
Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon l,
Alain Montfranc ?crivait dans fr.comp.applications.sgbd :
helios a présenté l'énoncé suivant :
rien en fait



sai marant lah plu groce baze de donnai komerssialeux aux monde ait...
chez FT et... sou Oracle !



Hell n'ait pa ke commerssialle, hell ait ossi teknique aveque en
plus d'aurakle pleins deux vraie boud de sibelle dedan.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Avatar
SQLpro
Mickaël Wolff a écrit :
Le 29/05/2010 10:14, SQLpro a écrit :
SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !



Tu as un lien qui explique ce qu'est une page ans ce contexte ?




1) un SGBDR lit les données sous forme de pages, une page peut faire de
2 à 64 Ko selon le SGBDR et l'OS sur lequel il est installé.

2) pour une démo de la chose (nombre de page lues par une requête
ordinaire et par la vue indexées, lire l'article que j'ai écrit à ce
sujet : http://sqlpro.developpez.com/optimisation/indexation/

A +

--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Avatar
helios
SQLpro a écrit :
Mickaël Wolff a écrit :
Le 29/05/2010 10:14, SQLpro a écrit :
SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !



Tu as un lien qui explique ce qu'est une page ans ce contexte ?




1) un SGBDR lit les données sous forme de pages, une page peut faire
de 2 à 64 Ko selon le SGBDR et l'OS sur lequel il est installé.




ou meme 2Go pour un SGBDR MV


2) pour une démo de la chose (nombre de page lues par une requête
ordinaire et par la vue indexées, lire l'article que j'ai écrit à ce
sujet : http://sqlpro.developpez.com/optimisation/indexation/

A +



PUB non vérifié par le BVP n'engageant que son auteur
Avatar
Alain Montfranc
helios a exposé le 05/06/2010 :
SQLpro a écrit :
Mickaël Wolff a écrit :
Le 29/05/2010 10:14, SQLpro a écrit :
SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !



Tu as un lien qui explique ce qu'est une page ans ce contexte ?




1) un SGBDR lit les données sous forme de pages, une page peut faire de 2 à
64 Ko selon le SGBDR et l'OS sur lequel il est installé.




ou meme 2Go pour un SGBDR MV



Ah c'est limité ces trucs ?
Avatar
helios
Alain Montfranc a écrit :
helios a exposé le 05/06/2010 :
SQLpro a écrit :
Mickaël Wolff a écrit :
Le 29/05/2010 10:14, SQLpro a écrit :
SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !



Tu as un lien qui explique ce qu'est une page ans ce contexte ?




1) un SGBDR lit les données sous forme de pages, une page peut faire
de 2 à 64 Ko selon le SGBDR et l'OS sur lequel il est installé.




ou meme 2Go pour un SGBDR MV



Ah c'est limité ces trucs ?




tout a une limite seul les sots pensent le contraire
Avatar
Alain Montfranc
helios avait soumis l'idée :
Alain Montfranc a écrit :
helios a exposé le 05/06/2010 :
SQLpro a écrit :
Mickaël Wolff a écrit :
Le 29/05/2010 10:14, SQLpro a écrit :
SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !



Tu as un lien qui explique ce qu'est une page ans ce contexte ?




1) un SGBDR lit les données sous forme de pages, une page peut faire de 2
à 64 Ko selon le SGBDR et l'OS sur lequel il est installé.




ou meme 2Go pour un SGBDR MV



Ah c'est limité ces trucs ?




tout a une limite seul les sots pensent le contraire



"hélios est limité" :-D

Au passage, des pages trop grandes, c'est une clownerie :-D
Avatar
Alain Montfranc
(supersedes <4c0b6fb9$0$27586$)

helios avait soumis l'idée :
Alain Montfranc a écrit :
helios a exposé le 05/06/2010 :
SQLpro a écrit :
Mickaël Wolff a écrit :
Le 29/05/2010 10:14, SQLpro a écrit :
SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !



Tu as un lien qui explique ce qu'est une page ans ce contexte ?




1) un SGBDR lit les données sous forme de pages, une page peut faire de
2 à 64 Ko selon le SGBDR et l'OS sur lequel il est installé.




ou meme 2Go pour un SGBDR MV



Ah c'est limité ces trucs ?




tout a une limite seul les sots pensent le contraire



Donc "hélios est limité" :-D CQFD (au passage vous ne connaissez pas
vos classiques, "deux choses sont infinies...", ou alors vous
considérez qu'Albert E. est un sot)

Au passage aussi, des pages trop grandes, c'est une clownerie :-D
Avatar
JKB
Le 06-06-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
Alain Montfranc ?crivait dans fr.comp.applications.sgbd :
(supersedes <4c0b6fb9$0$27586$)

helios avait soumis l'idée :
Alain Montfranc a écrit :
helios a exposé le 05/06/2010 :
SQLpro a écrit :
Mickaël Wolff a écrit :
Le 29/05/2010 10:14, SQLpro a écrit :
SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !



Tu as un lien qui explique ce qu'est une page ans ce contexte ?




1) un SGBDR lit les données sous forme de pages, une page peut faire de
2 à 64 Ko selon le SGBDR et l'OS sur lequel il est installé.




ou meme 2Go pour un SGBDR MV



Ah c'est limité ces trucs ?




tout a une limite seul les sots pensent le contraire



Donc "hélios est limité" :-D CQFD (au passage vous ne connaissez pas
vos classiques, "deux choses sont infinies...", ou alors vous
considérez qu'Albert E. est un sot)

Au passage aussi, des pages trop grandes, c'est une clownerie :-D



N'essayez pas de lui expliquer pourquoi, on va encore avoir ici un
fil dont rien ne sortira.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
1 2 3 4 5