Discussion :

[varex]

Bonjour,

je dois créer une application web qui permet de récupérer des enregistrements dans une table.

Cette base possède 4,2 millions d'enregistrements et une trentaine de champs.

Les critères de recherches sont exclusivement de type radio bouton et checkbox.

De plus, chaque fois qu'un critère est choisi (ou modifié), un comptage automatique du nombre d'enregistrement est mis à jour.

Le but pour l'instant avant d'avancer dans le projet est de trouver le moyen le plus rapide pour arriver à récupérer le nombre d'enregistrement.

Pour l'instant, la solution qu'on est en train de tester consiste à créer un champs 'filtre' dans la base qui est une chaine de caractère qui sera une sorte de filtre. Par exemple, comme critère, on a :
- email : oui (1) ou non (0);
- téléphone : oui (1) ou non (0);
- age : de 0 à 9 ans (0) , de 10 à 19 ans (1), de 20 à 29 ans (2), etc

donc, si un enregistrement possède un email, pas de téléphone et l'age est de 15, la valeur du filtre est : 101

Un index sur filtre a été créé.

Donc, par exemple pour trouver le nombre d'enregistrements qui ont un email et dont l'age est de 21 ans, on utilise la requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT count(*) FROM ma_table WHERE regexp_LIKE(filtre,'^1(0|1){1}2$')

Le problème, c'est que le l'index sur filtre n'est pas utilisé et la requête met 163 secondes pour retourner un résultat.

Je viens vous demander de l'aide pour savoir comment on peut utiliser l'index sur filtre.

Sinon, peut être que quelqu'un aura une autre méthode.

Merci d'avance

Petite précision :
J'utilise Oracle 10.2.0.3

[Ahmed AANGOUR]

Bonjour,

lorsqu'on a comme ça des filtres sur plusieurs champs et qui se combinent il vaut mieux utiliser des indexes BITMAP sur chaque champ. Oracle arrive bien à combiner ce type d'index et en plus ces indexes sont adéquates lorsque les colonnes ne sont pas très sélectives (c'est ton cas ici).

Par contre ces indexes sont à éviter si t'as bcp d'accès concurrents en DML sur cette table.

PS: les indexes bitmaps ne sont disponibles qu'avec l'enterprise edition

cdmt,
Ahmed

[varex]

Bonjour,

Merci de ta réponse.

Cela marche très bien pour les champs avec peu de choix possible :
- 4 champs avec 1 ou 0;
- 2 champs avec des valeurs allant de 0 à 8.

Par contre, la table possède deux champs qui ont respectivement 99 et 1442 valeurs possibles. Je les ai mis en index bitmap, mais cette méthode est moins efficace.

Existe t il une méthode pour pouvoir indexer les deux autres champs de manière plus efficace que les index bitmap?

[Ahmed AANGOUR]

Par contre, la table possède deux champs qui ont respectivement 99 et 1442 valeurs possibles. Je les ai mis en index bitmap, mais cette méthode est moins efficace.

99 et 1442 valeurs possible sur combien de lignes?

[varex]

chaque champs pour les 99 et 1442 est : 4 158 423

[Ahmed AANGOUR]

l'index bitmap devrait faire l'affaire car la selectivité des colonnes est faible mais surtout ce qui importe c'est la combinaison des indexes bitmap qui est performante.

[varex]

Merci de ton aide,

En fait, je trouvais que c'était assez lent, mais c'est de ma faute.

Dans la requête, dans le WHERE, j'avais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
WHERE 
.....
CRIT7(12,37,96,34,76,89,31,01,48)
.....

j'avais mis un index bitmap sur CRIT7 mais c'est un varchar2
Et mon index n'était pas utilisé.


Du coup en mettant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
WHERE 
.....
CRIT7('12','37','96','34','76','89','31','01','48')
.....

L'index est utilisé, et du coup, c'est plus rapide.

[Ahmed AANGOUR]

ok c'est cool.
N'oublie pas de faire attention si ta table connait des mises à jour concurrentielles tu peux avoir des soucis de perfs avec tes indexes bitmap en DML.

[varex]

Cette table est utilisée en lecture principalement.

Les changements dans la table seront plus qu'occasionnels, une fois par mois elle devrait être mise à jour.