sous requêtes, lenteurs et puissance du PC

zzzz

08/07/2011 à 11:48

On 8 juil, 10:08, zzzz wrote:

Bonjour,
Je travaille seul sur Access en local. On me demande de créer des
tableaux complexes avec plusieurs colonnes : effectifs élèves, taux d e
réussite aux examens, nombres de classes, taux de remplissage, par
commune, année n-5; n-4, etc... ce qui fait que pour créer mon tablea u
final j'utilise plusieurs requêtes (sélection, croisée, union...).
Résultat : l'exécution de la dernière requête est hyper lente.
J'ai un processeur de 1,8 GHz avec une RAM de 2 Go (1 Go à l'origine).
Le service informatique me dit que même si on me donne un PC plus
puissant ça ne changera rien. Quel est votre avis ?
Merci d'avance
Eric

précision : access 2003, win XP

Albéric

08/07/2011 à 18:21

C'est quoi hyper lente?
Combien de données ?
Est-ce bien indexé ?

"zzzz" a écrit dans le message de news:

Bonjour,
Je travaille seul sur Access en local. On me demande de créer des
tableaux complexes avec plusieurs colonnes : effectifs élèves, taux de
réussite aux examens, nombres de classes, taux de remplissage, par
commune, année n-5; n-4, etc... ce qui fait que pour créer mon tableau
final j'utilise plusieurs requêtes (sélection, croisée, union...).
Résultat : l'exécution de la dernière requête est hyper lente.
J'ai un processeur de 1,8 GHz avec une RAM de 2 Go (1 Go à l'origine).
Le service informatique me dit que même si on me donne un PC plus
puissant ça ne changera rien. Quel est votre avis ?
Merci d'avance
Eric

zzzz

08/07/2011 à 21:19

On 8 juil, 18:21, "Albéric" wrote:

C'est quoi hyper lente?
Combien de données ?
Est-ce bien indexé ?

je répondrais plus précisément lundi quand je serais au bureau
durée : une dizaine de minute.
au départ j'ai 5 tables identiques (années 2006 à 2010) : une
quinzaine de colonnes et environ 40 000 lignes pour chaque table
Pas dindexation, pas de clé primaire, je fais une requête union avec
ces 5 tables. Entre cette requête union et la requête finale il y a
environ 4 ou 5 niveaux de requêtes

Thierry

09/07/2011 à 10:40

Bonjour,
Clé primaire et indexation dans chaque table devraient résoudre votre
problème.
Vous passerez de 10 minutes à 1 minute ...
Bon courage.

"zzzz" a écrit dans le message de groupe de discussion :

On 8 juil, 18:21, "Albéric" wrote:

C'est quoi hyper lente?
Combien de données ?
Est-ce bien indexé ?

je répondrais plus précisément lundi quand je serais au bureau
durée : une dizaine de minute.
au départ j'ai 5 tables identiques (années 2006 à 2010) : une
quinzaine de colonnes et environ 40 000 lignes pour chaque table
Pas d’indexation, pas de clé primaire, je fais une requête union avec
ces 5 tables. Entre cette requête union et la requête finale il y a
environ 4 ou 5 niveaux de requêtes

Albéric

09/07/2011 à 13:10

Déjà avec une table par année, ça ne me plait pas.
Combien de temps prend votre requête union ?

Autant que possible, créez une seule table (avec votre requête union)
Ajoutez une clé primaire, c'est pas pour les chiens ;-)
* Il faut indexer* les champs sur lesquels vous mettez des critères, et rien
que ceux-là : trop d'index, ça tue aussi !
Ne pas oublier de compacter la base. Ce que je fais parfois c'est créer une
nouvelle base et y importer tous les objets, vous seriez surpris de la
différence de taille ! c'est mieux optimisé.

Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

Cdt,
Albéric.

Thierry

10/07/2011 à 06:38

En complément, voici un excellent site pour comprendre les index :

http://cerig.efpg.inpg.fr/tutoriel/bases-de-donnees/sommaire.htm

Bonne journée.

( _ /)
(='.'=)
(")-(") .
"zzzz" a écrit dans le message de groupe de discussion :

On 8 juil, 18:21, "Albéric" wrote:

C'est quoi hyper lente?
Combien de données ?
Est-ce bien indexé ?

je répondrais plus précisément lundi quand je serais au bureau
durée : une dizaine de minute.
au départ j'ai 5 tables identiques (années 2006 à 2010) : une
quinzaine de colonnes et environ 40 000 lignes pour chaque table
Pas d’indexation, pas de clé primaire, je fais une requête union avec
ces 5 tables. Entre cette requête union et la requête finale il y a
environ 4 ou 5 niveaux de requêtes

zzzz

11/07/2011 à 10:57

On 9 juil, 13:10, "Albéric" wrote:

Déjà avec une table par année, ça ne me plait pas. Combien de tem ps prend votre requête union ?

pour unir les 5 tables de 20 000 enreg et 42 champs, la requete union
sur 18 champs dure 3 secondes et des poussières.

Autant que possible, créez une seule table (avec votre requête union)

si je crée une table issue de la requete union des 5 tables (ce que je
fais des fois) --> inconvénient : penser à modifier la table issue de
la requête si cette dernière est modifiée.
Avec cette requete union je crée une requete de rang 2. la req de rang
2 me permet de créer une req de rang 3; avec les req de rang 2 et 3 je
crée une req de rang 4, etc...la requête finale (INNER JOIN) est cré ée
à partir de 10 requetes de rang 6 et 7.
La solution provisoire que j'utilise : je crée un première base avec
les requetes jusqu'au rang 4 et ces requetes de rang 4 sont exporté en
tant que tables dans une 2° base : la requête finale est un INNER JOIN
de 10 requêtes de rangs inférieurs. Mais même inconvénient que ci-
dessus si modif dans la 1re base.

Ajoutez une clé primaire, c'est pas pour les chiens ;-)

je vois bien l'utilité d'une clé primaire, mais dans mon cas, je ne
vois pas ...

* Il faut indexer* les champs sur lesquels vous mettez des critères, et rien que ceux-là : trop d'index, ça tue aussi !

exact, je vais tester...

Ne pas oublier de compacter la base.

je le fais régulièrement

Ce que je fais parfois c'est créer une nouvelle base et y importer
tous les objets, vous seriez surpris de la

différence de taille ! c'est mieux optimisé.

je vais essayer et vous tiendrais au courant

Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

merci

zzzz

12/07/2011 à 11:12

On 11 juil, 10:57, zzzz wrote:

On 9 juil, 13:10, "Albéric" wrote:> Déjà avec une table par année, ça ne me plait pas. Combien de temps prend v otre requête union ?

pour unir les 5 tables de 20 000 enreg et 42 champs, la requete union
sur 18 champs dure 3 secondes et des poussières.

> Autant que possible, créez une seule table (avec votre requête unio n)

si je crée une table issue de la requete union des 5 tables (ce que je
fais des fois) --> inconvénient : penser à modifier la table issue de
la requête si cette dernière est modifiée.
Avec cette requete union je crée une requete de rang 2. la req de rang
2 me permet de créer une req de rang 3; avec les req de rang 2 et 3 je
crée une req de rang 4, etc...la requête finale (INNER JOIN) est cr éée
à partir de 10 requetes de rang 6 et 7.
La solution provisoire que j'utilise : je crée un première base avec
les requetes jusqu'au rang 4 et ces requetes de rang 4 sont exporté en
tant que tables dans une 2° base : la requête finale est un INNER JOI N
de 10 requêtes de rangs inférieurs. Mais même inconvénient que ci -
dessus si modif dans la 1re base.

> Ajoutez une clé primaire, c'est pas pour les chiens ;-)

je vois bien l'utilité d'une clé primaire, mais dans mon cas, je ne
vois pas ...

> * Il faut indexer* les champs sur lesquels vous mettez des critères, et rien que ceux-là : trop d'index, ça tue aussi !

exact, je vais tester...

> Ne pas oublier de compacter la base.

je le fais régulièrement

Ce que je fais parfois c'est créer une nouvelle base et y importer
tous les objets, vous seriez surpris de la> différence de taille ! c'es t mieux optimisé.

je vais essayer et vous tiendrais au courant

> Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

merci

ce que j'ai fait : indexation de 8 champs, compactage, création d'une
nouvelle base et importation d'objets; je ne peux pas créer de clé
primaire car doublons partout...
Aucun changement entre les 2 bases, même délai d'exécution d'une avan t-
dernière requête (25 sec)

Ceci étant dit, toutes choses étant égales par ailleurs, même si c' est
bien indexé, etc... la question était :
même si on me donne un PC plus puissant ça ne changera rien. Quel est
votre avis ? A moins que ma question ne concerne pas le NGs MFPA ?

On 11 juil, 10:57, zzzz <eric.z...@club-internet.fr> wrote:

On 9 juil, 13:10, "Albéric" <alberic.mas...@gmail.com> wrote:> Déjà avec une table par année, ça ne me plait pas. Combien de temps prend v otre requête union ?

pour unir les 5 tables de 20 000 enreg et 42 champs, la requete union
sur 18 champs dure 3 secondes et des poussières.

> Autant que possible, créez une seule table (avec votre requête unio n)

si je crée une table issue de la requete union des 5 tables (ce que je
fais des fois) --> inconvénient : penser à modifier la table issue de
la requête si cette dernière est modifiée.
Avec cette requete union je crée une requete de rang 2. la req de rang
2 me permet de créer une req de rang 3; avec les req de rang 2 et 3 je
crée une req de rang 4, etc...la requête finale (INNER JOIN) est cr éée
à partir de 10 requetes de rang 6 et 7.
La solution provisoire que j'utilise : je crée un première base avec
les requetes jusqu'au rang 4 et ces requetes de rang 4 sont exporté en
tant que tables dans une 2° base : la requête finale est un INNER JOI N
de 10 requêtes de rangs inférieurs. Mais même inconvénient que ci -
dessus si modif dans la 1re base.

> Ajoutez une clé primaire, c'est pas pour les chiens ;-)

je vois bien l'utilité d'une clé primaire, mais dans mon cas, je ne
vois pas ...

> * Il faut indexer* les champs sur lesquels vous mettez des critères, et rien que ceux-là : trop d'index, ça tue aussi !

exact, je vais tester...

> Ne pas oublier de compacter la base.

je le fais régulièrement

Ce que je fais parfois c'est créer une nouvelle base et y importer
tous les objets, vous seriez surpris de la> différence de taille ! c'es t mieux optimisé.

je vais essayer et vous tiendrais au courant

> Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

merci

ce que j'ai fait : indexation de 8 champs, compactage, création d'une
nouvelle base et importation d'objets; je ne peux pas créer de clé
primaire car doublons partout...
Aucun changement entre les 2 bases, même délai d'exécution d'une avan t-
dernière requête (25 sec)

Ceci étant dit, toutes choses étant égales par ailleurs, même si c' est
bien indexé, etc... la question était :
même si on me donne un PC plus puissant ça ne changera rien. Quel est
votre avis ? A moins que ma question ne concerne pas le NGs MFPA ?

Vous avez filtré cet utilisateur ! Consultez son message

On 11 juil, 10:57, zzzz wrote:

On 9 juil, 13:10, "Albéric" wrote:> Déjà avec une table par année, ça ne me plait pas. Combien de temps prend v otre requête union ?

pour unir les 5 tables de 20 000 enreg et 42 champs, la requete union
sur 18 champs dure 3 secondes et des poussières.

> Autant que possible, créez une seule table (avec votre requête unio n)

si je crée une table issue de la requete union des 5 tables (ce que je
fais des fois) --> inconvénient : penser à modifier la table issue de
la requête si cette dernière est modifiée.
Avec cette requete union je crée une requete de rang 2. la req de rang
2 me permet de créer une req de rang 3; avec les req de rang 2 et 3 je
crée une req de rang 4, etc...la requête finale (INNER JOIN) est cr éée
à partir de 10 requetes de rang 6 et 7.
La solution provisoire que j'utilise : je crée un première base avec
les requetes jusqu'au rang 4 et ces requetes de rang 4 sont exporté en
tant que tables dans une 2° base : la requête finale est un INNER JOI N
de 10 requêtes de rangs inférieurs. Mais même inconvénient que ci -
dessus si modif dans la 1re base.

> Ajoutez une clé primaire, c'est pas pour les chiens ;-)

je vois bien l'utilité d'une clé primaire, mais dans mon cas, je ne
vois pas ...

> * Il faut indexer* les champs sur lesquels vous mettez des critères, et rien que ceux-là : trop d'index, ça tue aussi !

exact, je vais tester...

> Ne pas oublier de compacter la base.

je le fais régulièrement

Ce que je fais parfois c'est créer une nouvelle base et y importer
tous les objets, vous seriez surpris de la> différence de taille ! c'es t mieux optimisé.

je vais essayer et vous tiendrais au courant

> Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

merci

ce que j'ai fait : indexation de 8 champs, compactage, création d'une
nouvelle base et importation d'objets; je ne peux pas créer de clé
primaire car doublons partout...
Aucun changement entre les 2 bases, même délai d'exécution d'une avan t-
dernière requête (25 sec)

Ceci étant dit, toutes choses étant égales par ailleurs, même si c' est
bien indexé, etc... la question était :
même si on me donne un PC plus puissant ça ne changera rien. Quel est
votre avis ? A moins que ma question ne concerne pas le NGs MFPA ?

Albéric

21/07/2011 à 12:14

"zzzz" a écrit dans le message de news:

On 11 juil, 10:57, zzzz wrote:

On 9 juil, 13:10, "Albéric" wrote:> Déjà avec
une table par année, ça ne me plait pas. Combien de temps prend votre
requête union ?

Ceci étant dit, toutes choses étant égales par ailleurs, même si c'est
bien indexé, etc... la question était :
même si on me donne un PC plus puissant ça ne changera rien. Quel est
votre avis ? A moins que ma question ne concerne pas le NGs MFPA ?

Il est bien entendu qu'avec un PC + puissant vous aurez de meilleurs
résultats

Cdt, Albéric

Gloops

21/07/2011 à 17:17

zzzz a écrit, le 12/07/2011 11:12 :

On 11 juil, 10:57, zzzz wrote:
On 9 juil, 13:10, "Albéric" wrote:> Dé jà avec une table par année, ça ne me plait pas. Combien de temps p rend votre requête union ?

pour unir les 5 tables de 20 000 enreg et 42 champs, la requete union
sur 18 champs dure 3 secondes et des poussières.

Autant que possible, créez une seule table (avec votre requête un ion)

si je crée une table issue de la requete union des 5 tables (ce que je
fais des fois) --> inconvénient : penser à modifier la table issu e de
la requête si cette dernière est modifiée.
Avec cette requete union je crée une requete de rang 2. la req de ra ng
2 me permet de créer une req de rang 3; avec les req de rang 2 et 3 je
crée une req de rang 4, etc...la requête finale (INNER JOIN) est c réée
à partir de 10 requetes de rang 6 et 7.
La solution provisoire que j'utilise : je crée un première base av ec
les requetes jusqu'au rang 4 et ces requetes de rang 4 sont exporté en
tant que tables dans une 2° base : la requête finale est un INNER JOIN
de 10 requêtes de rangs inférieurs. Mais même inconvénient que ci-
dessus si modif dans la 1re base.

Ajoutez une clé primaire, c'est pas pour les chiens ;-)

je vois bien l'utilité d'une clé primaire, mais dans mon cas, je n e
vois pas ...

* Il faut indexer* les champs sur lesquels vous mettez des critères , et rien que ceux-là : trop d'index, ça tue aussi !

exact, je vais tester...

Ne pas oublier de compacter la base.

je le fais régulièrement

Ce que je fais parfois c'est créer une nouvelle base et y importer
tous les objets, vous seriez surpris de la> différence de taille ! c'est mieux optimisé.

je vais essayer et vous tiendrais au courant

Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

merci

ce que j'ai fait : indexation de 8 champs, compactage, création d'une
nouvelle base et importation d'objets; je ne peux pas créer de clé
primaire car doublons partout...

Si les champs de données comportent des doublons, ça n'empêche pas de
créer un champ NuméroAuto pour en faire une clef primaire.
Après on peut aussi s'interroger sur l'intérêt d'un index sur des c hamps
très utilisés, lequel peut accepter les doublons le cas échéant. Si
l'état doit sortir dans un ordre donné, ça risque de ne rien gâch er au
moment de l'exécution d'avoir ainsi défini des index, même avec dou blons.

Aucun changement entre les 2 bases, même délai d'exécution d'une avant-
dernière requête (25 sec)

Ceci étant dit, toutes choses étant égales par ailleurs, même s i c'est
bien indexé, etc... la question était :
même si on me donne un PC plus puissant ça ne changera rien. Quel e st
votre avis ? A moins que ma question ne concerne pas le NGs MFPA ?

Il y a une façon d'en avoir le cur net, c'est de se faire prêter u ne
machine dernier cri, et de lancer le traitement dessus, pour voir ce que
ça donne ;)

Logiquement, pour le même traitement, une machine plus puissante mettra
moins de temps, ne serait-ce qu'un peu. ça n'empêche pas que le rés ultat
puisse être décevant. Si on passe de trente à vingt minutes, il y a une
amélioration, ça n'empêchera pas l'utilisateur d'être déçu, d onc mettre
des sous pour en arriver là n'est pas forcément la meilleure approche .
Se pencher sur les détails de l'application et la pertinence des index a
des chances de donner une amélioration plus sensible dans le temps
d'exécution. ça aura aussi coûté des sous, puisqu'il faut mettre un
programmeur dessus, mais si le problème de temps de traitement ne
concerne qu'une application, ça risque d'être plus judicieux. Et le j our
où la machine lâchera et qu'on se retrouvera avec une machine plus
puissante, on aura amélioré sur les deux tableaux, c'est là que
l'application deviendra efficace.

Un temps il existait des sociétés de location de matériel informati que.
Je ne sais pas si ça existe toujours ? ça pourrait être une façon d'en
avoir le cur net quant à la piste matérielle. Pour la piste logici elle,
on est obligé de passer du temps dessus. Pas forcément beaucoup
d'ailleurs si c'est pour créer quelques index. Plus si on veut redéfi nir
complètement toute l'application. Je ne suis pas certain que nous en
sachions assez pour conseiller d'en arriver là.

zzzz a écrit, le 12/07/2011 11:12 :

On 11 juil, 10:57, zzzz<eric.z...@club-internet.fr> wrote:

On 9 juil, 13:10, "Albéric"<alberic.mas...@gmail.com> wrote:> Dé jà avec une table par année, ça ne me plait pas. Combien de temps p rend votre requête union ?

pour unir les 5 tables de 20 000 enreg et 42 champs, la requete union
sur 18 champs dure 3 secondes et des poussières.

Autant que possible, créez une seule table (avec votre requête un ion)

si je crée une table issue de la requete union des 5 tables (ce que je
fais des fois) --> inconvénient : penser à modifier la table issu e de
la requête si cette dernière est modifiée.
Avec cette requete union je crée une requete de rang 2. la req de ra ng
2 me permet de créer une req de rang 3; avec les req de rang 2 et 3 je
crée une req de rang 4, etc...la requête finale (INNER JOIN) est c réée
à partir de 10 requetes de rang 6 et 7.
La solution provisoire que j'utilise : je crée un première base av ec
les requetes jusqu'au rang 4 et ces requetes de rang 4 sont exporté en
tant que tables dans une 2° base : la requête finale est un INNER JOIN
de 10 requêtes de rangs inférieurs. Mais même inconvénient que ci-
dessus si modif dans la 1re base.

Ajoutez une clé primaire, c'est pas pour les chiens ;-)

je vois bien l'utilité d'une clé primaire, mais dans mon cas, je n e
vois pas ...

* Il faut indexer* les champs sur lesquels vous mettez des critères , et rien que ceux-là : trop d'index, ça tue aussi !

exact, je vais tester...

Ne pas oublier de compacter la base.

je le fais régulièrement

Ce que je fais parfois c'est créer une nouvelle base et y importer
tous les objets, vous seriez surpris de la> différence de taille ! c'est mieux optimisé.

je vais essayer et vous tiendrais au courant

Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

merci

ce que j'ai fait : indexation de 8 champs, compactage, création d'une
nouvelle base et importation d'objets; je ne peux pas créer de clé
primaire car doublons partout...

Si les champs de données comportent des doublons, ça n'empêche pas de
créer un champ NuméroAuto pour en faire une clef primaire.
Après on peut aussi s'interroger sur l'intérêt d'un index sur des c hamps
très utilisés, lequel peut accepter les doublons le cas échéant. Si
l'état doit sortir dans un ordre donné, ça risque de ne rien gâch er au
moment de l'exécution d'avoir ainsi défini des index, même avec dou blons.

Aucun changement entre les 2 bases, même délai d'exécution d'une avant-
dernière requête (25 sec)

Ceci étant dit, toutes choses étant égales par ailleurs, même s i c'est
bien indexé, etc... la question était :
même si on me donne un PC plus puissant ça ne changera rien. Quel e st
votre avis ? A moins que ma question ne concerne pas le NGs MFPA ?

Il y a une façon d'en avoir le cur net, c'est de se faire prêter u ne
machine dernier cri, et de lancer le traitement dessus, pour voir ce que
ça donne ;)

Logiquement, pour le même traitement, une machine plus puissante mettra
moins de temps, ne serait-ce qu'un peu. ça n'empêche pas que le rés ultat
puisse être décevant. Si on passe de trente à vingt minutes, il y a une
amélioration, ça n'empêchera pas l'utilisateur d'être déçu, d onc mettre
des sous pour en arriver là n'est pas forcément la meilleure approche .
Se pencher sur les détails de l'application et la pertinence des index a
des chances de donner une amélioration plus sensible dans le temps
d'exécution. ça aura aussi coûté des sous, puisqu'il faut mettre un
programmeur dessus, mais si le problème de temps de traitement ne
concerne qu'une application, ça risque d'être plus judicieux. Et le j our
où la machine lâchera et qu'on se retrouvera avec une machine plus
puissante, on aura amélioré sur les deux tableaux, c'est là que
l'application deviendra efficace.

Un temps il existait des sociétés de location de matériel informati que.
Je ne sais pas si ça existe toujours ? ça pourrait être une façon d'en
avoir le cur net quant à la piste matérielle. Pour la piste logici elle,
on est obligé de passer du temps dessus. Pas forcément beaucoup
d'ailleurs si c'est pour créer quelques index. Plus si on veut redéfi nir
complètement toute l'application. Je ne suis pas certain que nous en
sachions assez pour conseiller d'en arriver là.

Vous avez filtré cet utilisateur ! Consultez son message

zzzz a écrit, le 12/07/2011 11:12 :

On 11 juil, 10:57, zzzz wrote:
On 9 juil, 13:10, "Albéric" wrote:> Dé jà avec une table par année, ça ne me plait pas. Combien de temps p rend votre requête union ?

pour unir les 5 tables de 20 000 enreg et 42 champs, la requete union
sur 18 champs dure 3 secondes et des poussières.

Autant que possible, créez une seule table (avec votre requête un ion)

si je crée une table issue de la requete union des 5 tables (ce que je
fais des fois) --> inconvénient : penser à modifier la table issu e de
la requête si cette dernière est modifiée.
Avec cette requete union je crée une requete de rang 2. la req de ra ng
2 me permet de créer une req de rang 3; avec les req de rang 2 et 3 je
crée une req de rang 4, etc...la requête finale (INNER JOIN) est c réée
à partir de 10 requetes de rang 6 et 7.
La solution provisoire que j'utilise : je crée un première base av ec
les requetes jusqu'au rang 4 et ces requetes de rang 4 sont exporté en
tant que tables dans une 2° base : la requête finale est un INNER JOIN
de 10 requêtes de rangs inférieurs. Mais même inconvénient que ci-
dessus si modif dans la 1re base.

Ajoutez une clé primaire, c'est pas pour les chiens ;-)

je vois bien l'utilité d'une clé primaire, mais dans mon cas, je n e
vois pas ...

* Il faut indexer* les champs sur lesquels vous mettez des critères , et rien que ceux-là : trop d'index, ça tue aussi !

exact, je vais tester...

Ne pas oublier de compacter la base.

je le fais régulièrement

Ce que je fais parfois c'est créer une nouvelle base et y importer
tous les objets, vous seriez surpris de la> différence de taille ! c'est mieux optimisé.

je vais essayer et vous tiendrais au courant

Je crois qu'avec cela vous allez faire moins d'hypertension ;-)

merci

ce que j'ai fait : indexation de 8 champs, compactage, création d'une
nouvelle base et importation d'objets; je ne peux pas créer de clé
primaire car doublons partout...

Si les champs de données comportent des doublons, ça n'empêche pas de
créer un champ NuméroAuto pour en faire une clef primaire.
Après on peut aussi s'interroger sur l'intérêt d'un index sur des c hamps
très utilisés, lequel peut accepter les doublons le cas échéant. Si
l'état doit sortir dans un ordre donné, ça risque de ne rien gâch er au
moment de l'exécution d'avoir ainsi défini des index, même avec dou blons.

Aucun changement entre les 2 bases, même délai d'exécution d'une avant-
dernière requête (25 sec)

Ceci étant dit, toutes choses étant égales par ailleurs, même s i c'est
bien indexé, etc... la question était :
même si on me donne un PC plus puissant ça ne changera rien. Quel e st
votre avis ? A moins que ma question ne concerne pas le NGs MFPA ?

Il y a une façon d'en avoir le cur net, c'est de se faire prêter u ne
machine dernier cri, et de lancer le traitement dessus, pour voir ce que
ça donne ;)

Logiquement, pour le même traitement, une machine plus puissante mettra
moins de temps, ne serait-ce qu'un peu. ça n'empêche pas que le rés ultat
puisse être décevant. Si on passe de trente à vingt minutes, il y a une
amélioration, ça n'empêchera pas l'utilisateur d'être déçu, d onc mettre
des sous pour en arriver là n'est pas forcément la meilleure approche .
Se pencher sur les détails de l'application et la pertinence des index a
des chances de donner une amélioration plus sensible dans le temps
d'exécution. ça aura aussi coûté des sous, puisqu'il faut mettre un
programmeur dessus, mais si le problème de temps de traitement ne
concerne qu'une application, ça risque d'être plus judicieux. Et le j our
où la machine lâchera et qu'on se retrouvera avec une machine plus
puissante, on aura amélioré sur les deux tableaux, c'est là que
l'application deviendra efficace.

Un temps il existait des sociétés de location de matériel informati que.
Je ne sais pas si ça existe toujours ? ça pourrait être une façon d'en
avoir le cur net quant à la piste matérielle. Pour la piste logici elle,
on est obligé de passer du temps dessus. Pas forcément beaucoup
d'ailleurs si c'est pour créer quelques index. Plus si on veut redéfi nir
complètement toute l'application. Je ne suis pas certain que nous en
sachions assez pour conseiller d'en arriver là.

sous requêtes, lenteurs et puissance du PC

10 réponses

Veuillez sélectionner un problème