OVH Cloud OVH Cloud

index et performance

17 réponses
Avatar
Daniel
Salut
Connaissez-vous un site pour m'aider pour l'utilisation d'index dans les
tables

Je veux savoir s'il est vraiment utile pour certains champs car quand je
rajoute un index,la table grossit rapidement

Pour des champs avec des valeurs uniques c'est certain c'est utile mais je
ne suis par certain pour certains champs comme "inventaire" qui peut avoir
oui ou non
comme valeur

Le champ "inventaire" sert beaucoup dans mes requetes avec des criteres soit
a oui ou non dépendant des enregistrements voulus.

Bref ,je veux savoir dans quelles circonstances, les index sont VRAIMENT
utiles

Merci

10 réponses

1 2
Avatar
Raymond
Bonjour.

Un index accélère les requêtes sur les champs indexés ainsi que les
opérations de tri et de regroupement. Par exemple, si tu recherches des noms
particuliers d'employés dans un champ Nom, tu peux créer un index pour ce
champ pour accélérer la recherche d'un nom spécifique.
Les index sont indispensables dans les clés primaires.
Les index sont recommandés,sinon indispensables, pour les champs de
recherche et de tri.
pour tout le reste ça ne sert à rien.
--
@+
Raymond Access MVP.
http://access.seneque.free.fr/
http://users.skynet.be/mpfa/charte.htm pour une meilleure
efficacité de tes interventions sur MPFA.


"Daniel" a écrit dans le message de
news:
Salut
Connaissez-vous un site pour m'aider pour l'utilisation d'index dans les
tables

Je veux savoir s'il est vraiment utile pour certains champs car quand je
rajoute un index,la table grossit rapidement

Pour des champs avec des valeurs uniques c'est certain c'est utile mais je
ne suis par certain pour certains champs comme "inventaire" qui peut avoir
oui ou non
comme valeur

Le champ "inventaire" sert beaucoup dans mes requetes avec des criteres
soit

a oui ou non dépendant des enregistrements voulus.

Bref ,je veux savoir dans quelles circonstances, les index sont VRAIMENT
utiles

Merci




Avatar
3stone
Salut,


J'y ajouterai les champs qui sont clé externe (ou étrangère).


Ceci dit:
- la clé primaire est automatiquement indexée
- indexer les clés externes

Dans un second temps, comme le dit Raymond, indexer les champs qui
interviennent continuellement dans les recherches ou les tris...

Mais, ne surtout pas indexer les champs qui n'ont que peut de valeurs distinctes !
Totalement exclus:
- les booleans... type Oui/Non, Vrai/Faux,
- les champs qui ont des dixaines, voir des centaines de valeurs identiques...
- les champs qui ne subissent aucun traitement (ou rarement), comme une adresse...

Ceux-ci ne font que ralentir et gonfler la base et le trafic sur le réseau.

--
A+
Pierre (3stone) Access MVP
--------------------------------------
Une pour tous, tous pour une ;-)
http://users.skynet.be/mpfa/
--------------------------------------
Avatar
Daniel
Merci bien tu as bien répondu a ma question

Car j'avais mis des champs indexés car il servait souvent comme critere par
contre la valeur de ce champ de trouvait dans centaines( 600+)
d'enregistrements

ex: je fesais un trie et un critere sur des produits qui avait 116 comme
style et 505 comme couleur
Je dois avoir au-dessus de 2000 produits qui ont cette spécification
Alors comme tu dis, je suis mieux d'enlever l'index sur le champ style et
couleur et surtout le champ inventaire qui a comme valeur oui/non


"3stone" a écrit dans le message de
news:e$
Salut,


J'y ajouterai les champs qui sont clé externe (ou étrangère).


Ceci dit:
- la clé primaire est automatiquement indexée
- indexer les clés externes

Dans un second temps, comme le dit Raymond, indexer les champs qui
interviennent continuellement dans les recherches ou les tris...

Mais, ne surtout pas indexer les champs qui n'ont que peut de valeurs
distinctes !

Totalement exclus:
- les booleans... type Oui/Non, Vrai/Faux,
- les champs qui ont des dixaines, voir des centaines de valeurs
identiques...

- les champs qui ne subissent aucun traitement (ou rarement), comme une
adresse...


Ceux-ci ne font que ralentir et gonfler la base et le trafic sur le
réseau.


--
A+
Pierre (3stone) Access MVP
--------------------------------------
Une pour tous, tous pour une ;-)
http://users.skynet.be/mpfa/
--------------------------------------





Avatar
Daniel
Euh ????
Je viens de tester mes index...
si j'enleve 2 index qui sont inventaire et réservé dans une table qui ont
comme valeur oui/non , ca me prends 15sec de plus pour exécuter le
rapport....

Ca vient de contredire ce que vous avez dit...


"Daniel" a écrit dans le message de
news:
Salut
Connaissez-vous un site pour m'aider pour l'utilisation d'index dans les
tables

Je veux savoir s'il est vraiment utile pour certains champs car quand je
rajoute un index,la table grossit rapidement

Pour des champs avec des valeurs uniques c'est certain c'est utile mais je
ne suis par certain pour certains champs comme "inventaire" qui peut avoir
oui ou non
comme valeur

Le champ "inventaire" sert beaucoup dans mes requetes avec des criteres
soit

a oui ou non dépendant des enregistrements voulus.

Bref ,je veux savoir dans quelles circonstances, les index sont VRAIMENT
utiles

Merci




Avatar
Raymond
Bonjour.

Ca vient de contredire ce que vous avez dit...
c'est un raccourci un peu trop rapide. si c'était ça , on en mettrait de

partout des index.
Il faut faire un test sur la durée avec les deux solutions et chronométrer à
chaque fois et analyser.
Le temps initial est de combien ?
une base non compactée avec un défragmenteur en action et norton antivirus
en analyse peut demander 5 minutes de plus qu'avant. c'est pour ça qu'il
faut se placer dans les mêmes conditions.

--
@+
Raymond Access MVP.
http://access.seneque.free.fr/
http://users.skynet.be/mpfa/charte.htm pour une meilleure
efficacité de tes interventions sur MPFA.


"Daniel" a écrit dans le message de
news:
Euh ????
Je viens de tester mes index...
si j'enleve 2 index qui sont inventaire et réservé dans une table qui ont
comme valeur oui/non , ca me prends 15sec de plus pour exécuter le
rapport....

Ca vient de contredire ce que vous avez dit...



Avatar
Daniel
J'ai fait mes tests avec base compactés a chaque fois
et avec chronometre
rapport qui contient des commandes et l'inventaire
si le champ inventaire(oui/non ) et resérvé (oui/non) sont indexé , 4 sec
pas indexé, 20 sec
J'ai fait ces tests a 3 reprises...

J'ai 100 000 enregistrements dans la table de produit, 1500 produits en
inventaire
et 250 réservé dans les 1500 en inventaire






"Raymond" a écrit dans le message de
news:
Bonjour.

Ca vient de contredire ce que vous avez dit...
c'est un raccourci un peu trop rapide. si c'était ça , on en mettrait de

partout des index.
Il faut faire un test sur la durée avec les deux solutions et chronométrer
à

chaque fois et analyser.
Le temps initial est de combien ?
une base non compactée avec un défragmenteur en action et norton antivirus
en analyse peut demander 5 minutes de plus qu'avant. c'est pour ça qu'il
faut se placer dans les mêmes conditions.

--
@+
Raymond Access MVP.
http://access.seneque.free.fr/
http://users.skynet.be/mpfa/charte.htm pour une meilleure
efficacité de tes interventions sur MPFA.


"Daniel" a écrit dans le message de
news:
Euh ????
Je viens de tester mes index...
si j'enleve 2 index qui sont inventaire et réservé dans une table qui
ont


comme valeur oui/non , ca me prends 15sec de plus pour exécuter le
rapport....

Ca vient de contredire ce que vous avez dit...







Avatar
Raymond
Personnellement je ne vois pas pourquoi .

Tu es sûr que ces deux champs ne sont utilisés nulle part ? entête de groupe
ou je ne sais quoi d'autre ? le champ inventaire n'est jamais testé ?

pourrais tu me passer juste ton état et ta requête dans une base vierge ?
sans rien d'autre, pour voir la structure de ton état.

--
@+
Raymond Access MVP.
http://access.seneque.free.fr/
http://users.skynet.be/mpfa/charte.htm pour une meilleure
efficacité de tes interventions sur MPFA.


"Daniel" a écrit dans le message de
news:%
J'ai fait mes tests avec base compactés a chaque fois
et avec chronometre
rapport qui contient des commandes et l'inventaire
si le champ inventaire(oui/non ) et resérvé (oui/non) sont indexé , 4 sec
pas indexé, 20 sec
J'ai fait ces tests a 3 reprises...

J'ai 100 000 enregistrements dans la table de produit, 1500 produits en
inventaire
et 250 réservé dans les 1500 en inventaire


Avatar
Daniel
Salut

Disons que j'ai 1 etat et 2 sous-etat avec 4-5 requetes en tout
Avec tout ca prend 15 sec en tout

Oui les champs inventaire et réservé sont utilisés , je prends seulement
seulement les produits où inventaire =oui et réservé=oui


Mais dans le message suivant ,3stone me dit que c'est inutile de les indexer
meme s'ils sont utilisés dans les recherches...


mais 3stone a écrit
"Dans un second temps, comme le dit Raymond, indexer les champs qui
interviennent continuellement dans les recherches ou les tris...

Mais, ne surtout pas indexer les champs qui n'ont que peut de valeurs
distinctes !
Totalement exclus:
- les booleans... type Oui/Non, Vrai/Faux,
- les champs qui ont des dixaines, voir des centaines de valeurs
identiques...
- les champs qui ne subissent aucun traitement (ou rarement), comme une
adresse..."

il y a plusieurs requetes qui utilisent "inventaire et reservé" comme
critere dans le rapport

celle-ci prendre 3sec de plus si je n'indexe pas ces champs... mais étant
donné que le rapport utilise plusieurs fois ces 2 champs comme critere, le
rapport va
prendre en tout 15-20 sec de plus

SELECT [AUG INV FINI].STYLE, [AUG INV FINI].COULEUR, [AUG INV FINI].TYPE,
[AUG INV FINI].NOCOMMANDE, Count([AUG INV FINI].[NO ROULEAU]) AS NbreRlx,
Sum([QTE PIED]*4/3) AS V2Rlx
FROM [AUG INV FINI]
WHERE ((([AUG INV FINI].INVENTAIRE)=Yes) AND (([AUG INV FINI].réservé)=Yes))
GROUP BY [AUG INV FINI].STYLE, [AUG INV FINI].COULEUR, [AUG INV FINI].TYPE,
[AUG INV FINI].NOCOMMANDE
HAVING ((([AUG INV FINI].STYLE) Is Not Null) AND (([AUG INV FINI].COULEUR)
Is Not Null) AND (([AUG INV FINI].TYPE) Is Not Null) AND (([AUG INV
FINI].NOCOMMANDE) Is Not Null));



Merci !

"Raymond" a écrit dans le message de
news:
Personnellement je ne vois pas pourquoi .

Tu es sûr que ces deux champs ne sont utilisés nulle part ? entête de
groupe

ou je ne sais quoi d'autre ? le champ inventaire n'est jamais testé ?

pourrais tu me passer juste ton état et ta requête dans une base vierge ?
sans rien d'autre, pour voir la structure de ton état.

--
@+
Raymond Access MVP.
http://access.seneque.free.fr/
http://users.skynet.be/mpfa/charte.htm pour une meilleure
efficacité de tes interventions sur MPFA.


"Daniel" a écrit dans le message de
news:%
J'ai fait mes tests avec base compactés a chaque fois
et avec chronometre
rapport qui contient des commandes et l'inventaire
si le champ inventaire(oui/non ) et resérvé (oui/non) sont indexé , 4
sec


pas indexé, 20 sec
J'ai fait ces tests a 3 reprises...

J'ai 100 000 enregistrements dans la table de produit, 1500 produits en
inventaire
et 250 réservé dans les 1500 en inventaire






Avatar
3stone
Salut,

Daniel
Je viens de tester mes index...
si j'enleve 2 index qui sont inventaire et réservé dans une table qui ont
comme valeur oui/non , ca me prends 15sec de plus pour exécuter le
rapport....

Ca vient de contredire ce que vous avez dit...



Je ne voudrais pas de toi pour faire des stats nationales... ;-))

Bien sûr qu'avec un index cela peut, et souvent d'ailleurs, cela vas "plus vite"...
Mais, toi tu ne parle *que* de la requête que tu exécute...
et puis, 15sec... sur un temps global de combien ?

Fait le même test en mettant des index sur tous les champs... pour voir!

Ensuite, toi tu regarde "l'interrogation"... as tu vérifier à la saisie...
avec une dixaine d'utilisateurs qui saisissent sur c'est données...
ou Access doit tenir à jour des index sur des champs oui/non ??

Si toi tu n'es interesser que par la vitesse d'exécusion de la requête,
je ne vois pas pourquoi tu as posé la question... il te suffisait
de faire le test... et d'en tirer tes propres conclusions ;-)

Pour ma part, je répète que l'on indexe pas un boolean!


--
A+
Pierre (3stone) Access MVP
--------------------------------------
Une pour tous, tous pour une ;-)
http://users.skynet.be/mpfa/
--------------------------------------

Avatar
Raymond
Je prévoierais, comme je l'ai dit dans mon post, d'indexer tous les champs
de recherche et de tri, quel que soit le type, ce qui semble se confirmer
dans ton cas. Il faudrait peut-être avaliser tout ça par d'autres exemples
réels de grosse requête.

--
@+
Raymond Access MVP.
http://access.seneque.free.fr/
http://users.skynet.be/mpfa/charte.htm pour une meilleure
efficacité de tes interventions sur MPFA.


"Daniel" a écrit dans le message de
news:%
Salut

Disons que j'ai 1 etat et 2 sous-etat avec 4-5 requetes en tout
Avec tout ca prend 15 sec en tout

Oui les champs inventaire et réservé sont utilisés , je prends seulement
seulement les produits où inventaire =oui et réservé=oui


Mais dans le message suivant ,3stone me dit que c'est inutile de les
indexer

meme s'ils sont utilisés dans les recherches...


mais 3stone a écrit
"Dans un second temps, comme le dit Raymond, indexer les champs qui
interviennent continuellement dans les recherches ou les tris...

Mais, ne surtout pas indexer les champs qui n'ont que peut de valeurs
distinctes !
Totalement exclus:
- les booleans... type Oui/Non, Vrai/Faux,
- les champs qui ont des dixaines, voir des centaines de valeurs
identiques...
- les champs qui ne subissent aucun traitement (ou rarement), comme une
adresse..."

il y a plusieurs requetes qui utilisent "inventaire et reservé" comme
critere dans le rapport

celle-ci prendre 3sec de plus si je n'indexe pas ces champs... mais étant
donné que le rapport utilise plusieurs fois ces 2 champs comme critere, le
rapport va
prendre en tout 15-20 sec de plus

SELECT [AUG INV FINI].STYLE, [AUG INV FINI].COULEUR, [AUG INV FINI].TYPE,
[AUG INV FINI].NOCOMMANDE, Count([AUG INV FINI].[NO ROULEAU]) AS NbreRlx,
Sum([QTE PIED]*4/3) AS V2Rlx
FROM [AUG INV FINI]
WHERE ((([AUG INV FINI].INVENTAIRE)=Yes) AND (([AUG INV
FINI].réservé)=Yes))

GROUP BY [AUG INV FINI].STYLE, [AUG INV FINI].COULEUR, [AUG INV
FINI].TYPE,

[AUG INV FINI].NOCOMMANDE
HAVING ((([AUG INV FINI].STYLE) Is Not Null) AND (([AUG INV FINI].COULEUR)
Is Not Null) AND (([AUG INV FINI].TYPE) Is Not Null) AND (([AUG INV
FINI].NOCOMMANDE) Is Not Null));



Merci !



1 2