index et performance

Salut
Pour ce qui est de la saisie ,on a pas de problemes a ce niveau la
(maintenant)
Je sais que plus que tu as ajoutes d'index plus la bd grossit et je risque
d'avoir des erreur de verrouillages d'enregistrements et aures problemes de
lenteur réseau

J'avais trop d'index dans mes tables...

Maintenant dans mes grosses requetes j'ai environ 5 index sur 25 champs
noproduit(auto) style(numerique), couleur(numerique) , inventaire(oui/non),
réservé(oui/non) par exemple

et j'ai plus de problemes pour les saisies de donnees

Je DOIS mettre un index sur les champs "inventaire et réservé" parce qu'un
de mes rapports qui est tres lourd qui prend 5sec pour une page et le
rapport en a 70 pages pour un total de 250 sec pour imprimé les 70 pages
mais si j'enleve ces 2 index( booléean) ca va prendre 20sec chaque page x
70 pages = 1440sec pour imprimer le rapport !!

Alors d'apres moi, je crois que le mieux c'est trouver le meilleur compromis
entre performance pour les rapports et performance pour les entrées de
donnée

Tu persistes a croire qu'il ne faut pas indéxer un index et je te crois
Tu as plus de connaissance et d'experience a ce niveau
Par contre pour ma base de donnee ,l'indexation de boolean(pas tous bien
sur) est tres benéfique pour moi sans ralentir au niveau des saisies de
donnée
Je vais quand meme pas mettre un index sur chaque champ sans raison



Merci

"3stone" <3stone@skynet.be> a écrit dans le message de
news:%23KNhI3vdDHA.1588@TK2MSFTNGP12.phx.gbl...

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

Salut
Vous(3stone et vous) semblez croire qu'on ne devrait pas l'indexer un
boolean
Surement qu'il ne faut pas indexer de boolean lorsqu'il y a beaucoup de
saisies car cela risque de ralentir beaucoup au niveau du réseau et de la
saisie de donnee(probleme de verrouillage,etc)
Pour ma part, l'ampleur de la saisie de donnees n'est pas énorme ,toutefois
nous avons besoin de beaucoup de rapport pour gerer ces donnees....

Si nous avions beaucoup de saisies alors je suppose que nous devrions
limiter nos index pour ne pas nuir a nos usagers...

Merci pour votre aide a vous deux
Vous m'avez aider a comprendre l'importance d'indexer un champ ou pas...



"Raymond" <Raymond.seneque@free.fr> a écrit dans le message de
news:etmmW5vdDHA.3596@TK2MSFTNGP11.phx.gbl...

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" <no@spam.net> a écrit dans le message de
news:%23hoZMfvdDHA.3260@TK2MSFTNGP09.phx.gbl...

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 !

Salut,

Trouver une aiguille dans une botte de foin, c'est long... avec un
électro-aimant, c'est peut-être plus rapide... mais faut d'abord amener
l'électro-aimant près de la botte.

Sur un million d'enregistrements, je dois trouver le seul qui a la
valeur Faux sous le champ f1. Sans index, il faut traverser le million
d'enregistrements, avec index, une seule consultation est nécessaire. Un
index peut donc être utile, même sur un booléen.

Un meilleur critère semble plutôt être en relation du nombre relatif
d'enregistrements retournés, sur la discrimination apportée par l'index.
L'index est inutile, dans mon exemple, pour repérer les 999 999 valeurs
Vrai, mais des plus utiles pour retrouver celle qui est fausse. Est-ce que
je veux trouver l'aiguille, ou un brin de foin?


Il se peut que l'état à imprimer, de Daniel, ne concerne que les
enregistrements où son booléen est à vrai (ou à faux) parmi une masse de
valeurs opposée, et alors, l'index est utile.


À noter que si il y a peu d'enregistrements, un index est probablement
inutile, car parcourir toute la table est probablement plus rapide que de
charger l'index en mémoire!


Espérant être utile,
Vanderghast, Access MVP




"3stone" <3stone@skynet.be> wrote in message
news:e$dSWWidDHA.656@tk2msftngp13.phx.gbl...

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

Salut,


Éviter d'indexer deux fois. Certains champs, qui terminent par
certains suffixes ( suffixes listés sous Tools | Options ...
[Tables/Queries] ), sont automatiquement indexés. Ne pas ajouter un second
index sur un champ qui en aurait déjà un, en vertu de cette option.

Éviter les clés primaires en chaînes de caractères. Les bases de
données ont une propention à réutiliser cette valeur pour chaque index non
primaire créé sur la même table (un index "secondaire" emmagazine la valeur
indexée, et y fait correspondre la valeur de la clé primaire;
l'enregistrement est alors repéré avec une nouvelle consultation de l'index
primaire, qui lui se voit associé un numéro de "page" dans lequel on
retrouve l'entregistrement). Donc, si la clé primaire est "longue", cette
valeur est répétée pour chaque index, rendant la base de données plus
grande, et la quantité de data constituant l'index à transférer plus
volumineuse.


Ne pas indexer ce qui n'est pas "discriminable". Ne pas indexer les
petites tables, à moins qu'elles ne fassent parties de jointures complexes.

Tester. La présence ou non d'un index est plus souvent qu'autrement
évidente, mais si le besoin se fait sentir, expérimenter, tester.

Utiliser des expressions qui peuvent utiliser les index. Les Find,
de recordsets, ne sont pas réputés pour leur sagesse. "WHERE champ1 + 4 >
0" ne permet pas d'utiliser l'index sur champ1, de mênme, et encore plus
trivial,

WHERE Left(monJoliCodeAdministratif, 5) = "abc99"

est horrible. Une seule information par champ, dans ce cas, accélèrera
probablement beaucoup les choses.




Espérant être utile,
Vanderghast, Access MVP


"Daniel" <no@spam.net> wrote in message
news:OYSCpggdDHA.2356@TK2MSFTNGP09.phx.gbl...

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

Salut Michel

tu as tres bien expliqué l'utilité des index sur des champ booléean

J'ai 125000 enregistrements ... oui je sais je me repete ;)
2 booléean indéxés
1 qui s'appelle inventaire
environ 1000 a 2000 enregistrements ont comme valeur oui
Je me sers pas du reste des enregistrements
l'autre index est booléean est réservé
j'utilise seulement le critere réservé=oui avec inventaire=oui ce qui me
donne environ
250 enregistrements réservés qui sont en inventaire
c'est normal je réserve pas des produits pour des clients qui ne sont plus
en inventaire ;)

Je comprends tres bien que mettre un index sur un champ dont la valeur se
repete sur plus de la moitié des enregistrements est inutile

Meme si nous avions 10 000 enregistrements avec la meme valeur(ce qui n'est
pas le cas) ,l'index serait utile si la table aurait plus de 200 000
enregistrements par exemple

Par contre comme Raymond et 3stone disent, il ne faut pas tout indexer les
champs meme si ca serait efficace pour les requetes car cela nuirait
beaucoup a ceux qui entrent des données

Ca m'est deja arrivé, j'ai indexé 12 champs sur une table de 20 champs, je
peux vous dire
qu'on ressentait un certain ralentissement lors des saisies de données
maintenant je n'indexe pas plus de 5 champs par table et je n'ai plus de
probleme



"Michel Walsh" <vanderghast@msn.com> a écrit dans le message de
news:uddBg$6dDHA.1472@TK2MSFTNGP12.phx.gbl...

Salut,

Trouver une aiguille dans une botte de foin, c'est long... avec un
électro-aimant, c'est peut-être plus rapide... mais faut d'abord amener
l'électro-aimant près de la botte.

Sur un million d'enregistrements, je dois trouver le seul qui a la
valeur Faux sous le champ f1. Sans index, il faut traverser le million
d'enregistrements, avec index, une seule consultation est nécessaire. Un
index peut donc être utile, même sur un booléen.

Un meilleur critère semble plutôt être en relation du nombre relatif
d'enregistrements retournés, sur la discrimination apportée par l'index.
L'index est inutile, dans mon exemple, pour repérer les 999 999 valeurs
Vrai, mais des plus utiles pour retrouver celle qui est fausse. Est-ce que
je veux trouver l'aiguille, ou un brin de foin?


Il se peut que l'état à imprimer, de Daniel, ne concerne que les
enregistrements où son booléen est à vrai (ou à faux) parmi une masse de
valeurs opposée, et alors, l'index est utile.


À noter que si il y a peu d'enregistrements, un index est probablement
inutile, car parcourir toute la table est probablement plus rapide que de
charger l'index en mémoire!


Espérant être utile,
Vanderghast, Access MVP




"3stone" <3stone@skynet.be> wrote in message
news:e$dSWWidDHA.656@tk2msftngp13.phx.gbl...

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

Bonsoir.

Par contre comme Raymond et 3stone disent, il ne faut pas tout indexer les
champs meme si ca serait efficace pour les requetes car cela nuirait
beaucoup a ceux qui entrent des données

je te rappelle mon post de 20:15 hier

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.

j'ai bien précisé: quel que soit le type ce qui englobe boolean.
--
@+
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" <no@spam.net> a écrit dans le message de
news:e13Z2U9dDHA.3528@tk2msftngp13.phx.gbl...

Salut Michel

tu as tres bien expliqué l'utilité des index sur des champ booléean

Ouf ! Merci
Tout ce que vous venez de me dire m'est tres utiles
J'ai des index en double , je savais pas qu'il y avait des index automatique
:P, je vais les corriger
J'ai des clef primaire en texte, je vais "essayer" egalement de corriger ca

des expressions comme champ1+champ2, j'en ai beaucoup
Ouf, j'ai du ménage a faire ;)

Merci encore !!


"Michel Walsh" <vanderghast@msn.com> a écrit dans le message de
news:%23dfzgH7dDHA.2648@TK2MSFTNGP10.phx.gbl...

Salut,


Éviter d'indexer deux fois. Certains champs, qui terminent par
certains suffixes ( suffixes listés sous Tools | Options ...
[Tables/Queries] ), sont automatiquement indexés. Ne pas ajouter un second
index sur un champ qui en aurait déjà un, en vertu de cette option.

Éviter les clés primaires en chaînes de caractères. Les bases de
données ont une propention à réutiliser cette valeur pour chaque index non
primaire créé sur la même table (un index "secondaire" emmagazine la
valeur

indexée, et y fait correspondre la valeur de la clé primaire;
l'enregistrement est alors repéré avec une nouvelle consultation de
l'index

primaire, qui lui se voit associé un numéro de "page" dans lequel on
retrouve l'entregistrement). Donc, si la clé primaire est "longue", cette
valeur est répétée pour chaque index, rendant la base de données plus
grande, et la quantité de data constituant l'index à transférer plus
volumineuse.


Ne pas indexer ce qui n'est pas "discriminable". Ne pas indexer
les

petites tables, à moins qu'elles ne fassent parties de jointures
complexes.

Tester. La présence ou non d'un index est plus souvent
qu'autrement

évidente, mais si le besoin se fait sentir, expérimenter, tester.

Utiliser des expressions qui peuvent utiliser les index. Les Find,
de recordsets, ne sont pas réputés pour leur sagesse. "WHERE champ1 + 4 >
0" ne permet pas d'utiliser l'index sur champ1, de mênme, et encore plus
trivial,

WHERE Left(monJoliCodeAdministratif, 5) = "abc99"

est horrible. Une seule information par champ, dans ce cas, accélèrera
probablement beaucoup les choses.




Espérant être utile,
Vanderghast, Access MVP


"Daniel" <no@spam.net> wrote in message
news:OYSCpggdDHA.2356@TK2MSFTNGP09.phx.gbl...

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