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

Alain Montfranc a écrit :

helios a écrit :

Alain Montfranc a écrit :

Dans son message précédent, Eric Demeester a écrit :

dans (in) fr.comp.applications.sgbd, WebShaker <etienne@tlk.fr>
ecrivait (wrote) :

Bonjour Étienne,

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

C'est tellement évident que personne n'a évoqué ce point, mais as-tu
défini des index pertinents dans tes tables ?

Les suivantes sont encore pire...
Dans touts les cas, il me faut parcourir la table commandline.

Même remarque, en définissant de bons index, tu devrais gagner
beaucoup
de temps dans le traitemen des requètes.

Index ou pas, il y aura un scan de toute la base

et avec les jointures cela multiplie le temps de scan

si jointure, alors index accellere - relire cours

si le fichier n'a pas de jointure il est scanné plus rapidement qu un
fichier qui a des jointures car dans le premier cas le temps de faire
les jointures egale 0

scanner un article de fichier sans jointure c'est lire un article
scanner un article de fichier avec jointures c'est lire un article (plus
petit) puis aller voir les "renvois" vers autres fichiers definie par
les jointures donc c'est plus long

exemple

sans jointure :

*Nicolas Sarkozy* (*Nicolas Paul Stéphane Sarközy de Nagy-Bocsa*), né le
28 <http://fr.wikipedia.org/wiki/28_janvier> janvier
<http://fr.wikipedia.org/wiki/Janvier> 1955
<http://fr.wikipedia.org/wiki/1955> dans le 17^e arrondissement
<http://fr.wikipedia.org/wiki/17e_arrondissement_de_Paris> de Paris
<http://fr.wikipedia.org/wiki/Paris>, est un homme d'État
<http://fr.wikipedia.org/wiki/Homme_d%27%C3%89tat> français
<http://fr.wikipedia.org/wiki/France>.


avec jointures:

*"prenom x fiche prenom" Sarkozy* (*"prenom x fiche prenom"** **"prenom
y fiche prenom"** **"prenom z fich prenom"** Sarközy de Nagy-Bocsa*), né
le 28 <http://fr.wikipedia.org/wiki/28_janvier> janvier
<http://fr.wikipedia.org/wiki/Janvier> 1955
<http://fr.wikipedia.org/wiki/1955> dans le 17^e arrondissement
<http://fr.wikipedia.org/wiki/17e_arrondissement_de_Paris> de "ville x
fichier ville" <http://fr.wikipedia.org/wiki/Paris>, est un "profession
z fichier profession" <http://fr.wikipedia.org/wiki/Homme_d%27%C3%89tat>

laquel de ces deux fiche est la plus rapide a lire ?

Le 24-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

Alain Montfranc a écrit :

helios a écrit :

Alain Montfranc a écrit :

Dans son message précédent, Eric Demeester a écrit :

dans (in) fr.comp.applications.sgbd, WebShaker <etienne@tlk.fr>
ecrivait (wrote) :

Bonjour Étienne,

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

C'est tellement évident que personne n'a évoqué ce point, mais as-tu
défini des index pertinents dans tes tables ?

Les suivantes sont encore pire...
Dans touts les cas, il me faut parcourir la table commandline.

Même remarque, en définissant de bons index, tu devrais gagner
beaucoup
de temps dans le traitemen des requètes.

Index ou pas, il y aura un scan de toute la base

et avec les jointures cela multiplie le temps de scan

si jointure, alors index accellere - relire cours

si le fichier n'a pas de jointure il est scanné plus rapidement qu un
fichier qui a des jointures car dans le premier cas le temps de faire
les jointures egale 0

scanner un article de fichier sans jointure c'est lire un article
scanner un article de fichier avec jointures c'est lire un article (plus
petit) puis aller voir les "renvois" vers autres fichiers definie par
les jointures donc c'est plus long

exemple

sans jointure :

*Nicolas Sarkozy* (*Nicolas Paul Stéphane Sarközy de Nagy-Bocsa*), né le
28 <http://fr.wikipedia.org/wiki/28_janvier> janvier
<http://fr.wikipedia.org/wiki/Janvier> 1955
<http://fr.wikipedia.org/wiki/1955> dans le 17^e arrondissement
<http://fr.wikipedia.org/wiki/17e_arrondissement_de_Paris> de Paris
<http://fr.wikipedia.org/wiki/Paris>, est un homme d'État
<http://fr.wikipedia.org/wiki/Homme_d%27%C3%89tat> français
<http://fr.wikipedia.org/wiki/France>.


avec jointures:

*"prenom x fiche prenom" Sarkozy* (*"prenom x fiche prenom"** **"prenom
y fiche prenom"** **"prenom z fich prenom"** Sarközy de Nagy-Bocsa*), né
le 28 <http://fr.wikipedia.org/wiki/28_janvier> janvier
<http://fr.wikipedia.org/wiki/Janvier> 1955
<http://fr.wikipedia.org/wiki/1955> dans le 17^e arrondissement
<http://fr.wikipedia.org/wiki/17e_arrondissement_de_Paris> de "ville x
fichier ville" <http://fr.wikipedia.org/wiki/Paris>, est un "profession
z fichier profession" <http://fr.wikipedia.org/wiki/Homme_d%27%C3%89tat>

laquel de ces deux fiche est la plus rapide a lire ?

Les jointures ne sont pas là pour obvier aux défauts de structures
de tes base. Retourne lire tes cours ! Par ailleurs, les jointures
dans ton exemple sont remplacées par des tests de cohérence dans ta
table unique, sinon, on ne parle plus du tout de la même chose. Tu
oublies aussi au passage la taille occupée et le déplacement des
têtes, donc les temps d'accès qui ne sont pas négligeables dans le
cas d'une grosse table unique. Bref, comme à ton habitude, tu
mélanges des torchons et des serviettes pour faire croire que tu
comprends quelque chose.

Tu ferais bien d'arrêter, tu t'enfonces.

JKB

PS: réponds n'importe quoi comme à ton habitude, JE NE TE RÉPONDRAI PAS.

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

Alain Montfranc a écrit :

helios a écrit :

Alain Montfranc a écrit :

Dans son message précédent, Eric Demeester a écrit :

dans (in) fr.comp.applications.sgbd, WebShaker <etienne@tlk.fr>
ecrivait (wrote) :

Bonjour Étienne,

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

C'est tellement évident que personne n'a évoqué ce point, mais as-tu
défini des index pertinents dans tes tables ?

Les suivantes sont encore pire...
Dans touts les cas, il me faut parcourir la table commandline.

Même remarque, en définissant de bons index, tu devrais gagner
beaucoup
de temps dans le traitemen des requètes.

Index ou pas, il y aura un scan de toute la base

et avec les jointures cela multiplie le temps de scan

si jointure, alors index accellere - relire cours

l'informatique defis les regles de la réalité ?

desolé mais dans la realité il est toujours plus rapide de lire une
fiches complete que de lire une fiche qui fait des jointures (renvois)
vers d'autre fiche
en informatique il en est de meme


libre a qui le veux d'avoir des phantasmes qui dise que en informatique
la réalité ne s'applique pas

fin de troll

helios a présenté l'énoncé suivant :

Alain Montfranc a écrit :

helios a écrit :

Alain Montfranc a écrit :

Dans son message précédent, Eric Demeester a écrit :

dans (in) fr.comp.applications.sgbd, WebShaker <etienne@tlk.fr>
ecrivait (wrote) :

Bonjour Étienne,

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

C'est tellement évident que personne n'a évoqué ce point, mais as-tu
défini des index pertinents dans tes tables ?

Les suivantes sont encore pire...
Dans touts les cas, il me faut parcourir la table commandline.

Même remarque, en définissant de bons index, tu devrais gagner beaucoup
de temps dans le traitemen des requètes.

Index ou pas, il y aura un scan de toute la base

et avec les jointures cela multiplie le temps de scan

si jointure, alors index accellere - relire cours

l'informatique defis les regles de la réalité ?

ce forum est francophone - merci

desolé mais dans la realité il est toujours plus rapide de lire une fiches
complete que de lire une fiche qui fait des jointures (renvois) vers d'autre
fiche
en informatique il en est de meme


libre a qui le veux d'avoir des phantasmes qui dise que en informatique la
réalité ne s'applique pas

fin de troll

Le Sat, 22 May 2010 00:04:46 +0200
WebShaker <etienne@tlk.fr> a écrit :

> Une ou des tables temporaires ou en mémoire pourquoi pas, mais c'est
> surtout utile si ça te permet de permet de faire des agrégats qui
> resserviront plusieurs fois (donc ça dépend de tes requêtes) ou si
> ça te permet de travailler sur une table réduite (avec moins de
> colonnes), qui peut du coup tenir en mémoire.

Hum...
Mon idée c'est surtout de dupliquer les données tous les soirs dans
de nouvelles tables regroupant plusieurs tables. (Voir si c'est
possible un jour de ne plus dupliquer intégralement mais mettre en
jour en fct des données modifiées.)

Pour la grande table unique, je ne sais pas si ça va être plus
efficace, il faudra tout charger pour chaque requête... Sauf si elle
tient complètement en mémoire et qu'il n'y a plus qu'elle peut-être,
mais si tes tables tiennent déjà en mémoire...

Sais-tu si ce sont les accès disque ou si c'est le processeur qui
limite la rapidité de tes traitements ? Ça peut être intéressant. La
question c'est un peu : tu as 16 Go de mémoire, est-ce que ça permet
au SGBD de tout garder en mémoire ou non ? Les solutions ne seront pas
forcément les mêmes.

La modification incrémentielle de tes tables, ça peut être une bonne
piste.

Par exemple fusionner les tables produits, commandline, commande, bl
et facture dans une seule table puisque pour chaque ligne de commande
j'ai évidement qu'une seule commande, une seule facture, un seul
produit. bon pour les bl c'est plus complexe à cause des reliquats et
livraison partielle.

je pense que le temps pris pour générer cette table sera conséquent
mais me permettra de faire des requêtes avec nettement moins de
jointure. Par contre quasiment toutes les requêtes liront alors
l'intégralité de la table puisque compter le nombre de factures va
devenir

SELECT count(DISTINCT idfacture) FROM compact_table;

Alors qu'avant je faisais un

SELECT count(*) FROM facture;

La table était plus petite et donc la requête plus rapide.

L'interet supplementaire d'une table unique est qu'il devient
extrêment simple de réaliser un outil permettant à chaque utilisate ur
de créer ses propres graphes.
par exemple supposons qu'un de mes patrons soit intéressé par un
graph de CA / region de livraison.

Tu as regardé les cubes multidimensionnels (par exemple avec
Mondrian/JPivot en Java) ? Ça pourrait t'intéresser.

Le Tue, 25 May 2010 09:47:46 +0200
WebShaker <etienne@tlk.fr> a écrit :

Le 24/05/2010 20:46, Yliur a écrit :
> Pour la grande table unique, je ne sais pas si ça va être plus
> efficace, il faudra tout charger pour chaque requête... Sauf si elle
> tient complètement en mémoire et qu'il n'y a plus qu'elle peut-êt re,
> mais si tes tables tiennent déjà en mémoire...
>
> Sais-tu si ce sont les accès disque ou si c'est le processeur qui
> limite la rapidité de tes traitements ? Ça peut être intéressan t. La
> question c'est un peu : tu as 16 Go de mémoire, est-ce que ça permet
> au SGBD de tout garder en mémoire ou non ? Les solutions ne seront
> pas forcément les mêmes.
>
> La modification incrémentielle de tes tables, ça peut être une bo nne
> piste.

Hum tu as tout a fait raison.

nom cas est étroitement lié au materiel utilisé.
je suppose que toutes ma base va tenir en RAM en effet.
Lorsque je la dump elle est bien moins grosse que la mémoire dont je
dispose. (le me fait 1.3 go)

Attention, si tu fais une grande table unique ça peut prendre plus de
place que ça parce que certaines informations vont être dupliquées.
Essaie de calculer à la main combien de mémoire peut prendre cette
table.

Et justement l'idée de tout fusionner dans une seule table (je
l'espère) permettra a tous les processus de lire la même zone mémoi re.

Actuellement mon problème avec les tas de jointure que je fais c'est
que postgres alloue (enfin je pense) de la mémoire pour chaque
processus puisque les requêtes croisent des tables éventuellement
différentes. Et donc je suppose qu'il n'arrive pas a mutualiser le
cache. car la ressource problèmatique aujourd'hui des clairement les
IO. Et donc pas conséquent la Ram que j'utilise en trop grosse
quantité lors de requête concurrente.

Autant que je me souvienne, Postgres se repose pas mal sur le cache
système. Donc il ne devrait pas y avoir de problème de partage du cache
à ce niveau. La mémoire peut être consommée par les jointures ou par
les tris je pense.

D'où une autre idée que je suis en train d'évaluer.
Installer un deuxième postgres et le faire tourner dans un ram disque.
Dans ce cas, ma fameuse table fusionnée (qui peut être reconstruite
sans problème en cas de perte de ma base) serait créé dans ce ram
disque. Et là, je devrais obtenir des performances assez élevée.

Pour l'écrire, peut-être (même pas sûr, puisque tu vas avoir encore
moins de mémoire qu'avant pour faire tes jointures pour créer ta
table fusionnée). Pour la lire, elle restera peut-être dans le cache
système de toutes manières, donc si tu tentes de réaliser ta table
fusionnée, essaie d'abord dans ton installation actuelle plutôt que de
te casser les pieds avec un disque en mémoire, ça marchera peut-être.

Il faudrait pas contre que j'arrive à desactiver les caches disque
qui ne seront plus utile et risque de bouffer de la mémoire
inutilement.

En principe le cache système ne devrait pas faire trop concurrence à
l'utilisation principale de la mémoire.

Bref tout ca c'est des tests de grande envergure... qui si ca se
trouve ne vont déboucher sur rien du tout :)

> Tu as regardé les cubes multidimensionnels (par exemple avec
> Mondrian/JPivot en Java) ? Ça pourrait t'intéresser.

Je connais le concept des cubes, mais rien de plus.
Faudrait que j'en trouve un open source qui tourne sous linux pour
faire des essais.

Par contre, je supporte pas le java :)
alors pas en java.

Etienne

Je ne connais pas d'outils dans d'autres langages, mais ça se trouve
sans doute. Ceci dit les outils que j'ai cités ne demandent pas
tellement de faire du Java, la configuration de Mondrian est à base
de XML. Sauf si tu veux bidouiller le moteur ou le rendu.

WebShaker a écrit :

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

la solution est de mettre en place une vue matérialisée (Oracle, DB2) ou
indexées (SQL Server).

Exemple sous MS SQL Server :

CREATE VIEW dbo.V_commandline
WITH SCHEMABINDING
AS
SELECT ref, count_big(*) AS NOMBRE
FROM dbo.commandline
GROUP BY ref;
GO

CREATE UNIQUE CLUSTERED INDEX X_V_commandline
ON dbo.V_commandline (ref);

Dès lors votre requête :

SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !

A +

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

--
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 *************************

SQLpro a écrit :

WebShaker a écrit :

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

la solution est de mettre en place une vue matérialisée (Oracle, DB2)
ou indexées (SQL Server).

Exemple sous MS SQL Server :

CREATE VIEW dbo.V_commandline
WITH SCHEMABINDING
AS
SELECT ref, count_big(*) AS NOMBRE
FROM dbo.commandline
GROUP BY ref;
GO

CREATE UNIQUE CLUSTERED INDEX X_V_commandline
ON dbo.V_commandline (ref);

Dès lors votre requête :

SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !

A +

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets ????

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

SQLpro a écrit :

WebShaker a écrit :

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

la solution est de mettre en place une vue matérialisée (Oracle, DB2)
ou indexées (SQL Server).

Exemple sous MS SQL Server :

CREATE VIEW dbo.V_commandline
WITH SCHEMABINDING
AS
SELECT ref, count_big(*) AS NOMBRE
FROM dbo.commandline
GROUP BY ref;
GO

CREATE UNIQUE CLUSTERED INDEX X_V_commandline
ON dbo.V_commandline (ref);

Dès lors votre requête :

SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !

A +

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets ????

Tu es vraiment un abruti de première classe avec palme et
fourragère [1]. Lâche-le avec ça. Si tout le monde ici te mettait à
chacune de tes interventions nullissimes le nez dans tes erreurs, on
n'en finirait pas !

Quant à la discussion actuelle sur Wikipedia, elle montre à tous
ceux qui ne te connaissait pas encore la profondeur de tes
connaissances. Tout ce que tu prétends faire avec PICK, on peut le
faire au moins aussi bien avec SQL (et ce n'est pas une histoire de
lisibilité). Ce que je n'arrive pas à comprendre, c'est qu'il y ait
encore quelqu'un à jouer avec toi sur Wikipedia. Un autre mystère
est pour moi ta capacité à prétendre faire des choses avec un
système de base de données sans en connaître le fonctionnement
interne minimal ! Et je passe sur le fait que tu racontes un peu
partout des exploits professionnels à des endroits où j'aurais dû te
voir...

JKB

[1] et je ne parlerai pas de ton doctorat, parce qu'il y aurait beaucoup
de choses à dire. Que les nouveaux venus recherchent dans les archives
de ce groupe.

PS: répond ce que tu veux, je n'entrerai pas dans ton jeu.

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

JKB a écrit :

Le 29-05-2010, ? propos de
Re: optimiser une requete qui doit de toute façon lire toute la base,
helios ?crivait dans fr.comp.applications.sgbd :

SQLpro a écrit :

WebShaker a écrit :

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

la solution est de mettre en place une vue matérialisée (Oracle, DB2)
ou indexées (SQL Server).

Exemple sous MS SQL Server :

CREATE VIEW dbo.V_commandline
WITH SCHEMABINDING
AS
SELECT ref, count_big(*) AS NOMBRE
FROM dbo.commandline
GROUP BY ref;
GO

CREATE UNIQUE CLUSTERED INDEX X_V_commandline
ON dbo.V_commandline (ref);

Dès lors votre requête :

SELECT ref, count(*) FROM commandline GROUP BY ref
Mettra 0 secondes et consommera environ 2 pages !

A +

et le codagedes dates depuis JC à nos jours peut se faire sur 2octets ????

Tu es vraiment un abruti de première classe avec palme et
fourragère [1]. Lâche-le avec ça. Si tout le monde ici te mettait à
chacune de tes interventions nullissimes le nez dans tes erreurs, on
n'en finirait pas !

Quant à la discussion actuelle sur Wikipedia, elle montre à tous
ceux qui ne te connaissait pas encore la profondeur de tes
connaissances. Tout ce que tu prétends faire avec PICK, on peut le
faire au moins aussi bien avec SQL (et ce n'est pas une histoire de
lisibilité). Ce que je n'arrive pas à comprendre, c'est qu'il y ait
encore quelqu'un à jouer avec toi sur Wikipedia. Un autre mystère
est pour moi ta capacité à prétendre faire des choses avec un
système de base de données sans en connaître le fonctionnement
interne minimal ! Et je passe sur le fait que tu racontes un peu
partout des exploits professionnels à des endroits où j'aurais dû te
voir...

JKB

[1] et je ne parlerai pas de ton doctorat, parce qu'il y aurait beaucoup
de choses à dire. Que les nouveaux venus recherchent dans les archives
de ce groupe.

PS: répond ce que tu veux, je n'entrerai pas dans ton jeu.

je te signales que les endroits ou tu pretend que tu aurais du me voir
toi tu y etait pas car tes justificatifs de presence etait incoherent
style je rentre dans un etablissement sans que le patron le sache ......

je vais te donner tient une preuve une des peri42c se nomme ADSL.COV et
a ete ecrite par Cliquet Jacky UIC le 01/06/2003 et c'est le " Programme
permettant de connaitre le nombre de clients sur un Centre
Afin de savoir la possibilite d'un furture couverture ADSL"

alors si tu a vraiment ete a france telecom tu doit pouvoir me donner le
nom d'une autre peri42C avec son auteur et son role