Discussion :

[_Mac_]

Bonjour à tous,

Voici une question que tout le monde doit se poser : comment choisir les colonnes à indexer ? Ca a l'air bête, comme question, mais je ne sais pas quoi faire.

Dans mon cas concret, j'ai une table contenant des traces de logs : j'ai une colonne "id" (alimentée par une séquence) comme clé primaire, une colonne "date", une colonne "niveau" (debug, info, etc.), et une colonne "message". J'ai activé la contrainte de clé primaire, donc pour le moment je n'ai qu'un seul index sur la colonne ID. Je pense que les utilisateurs voudront faire des recherches pour compter ou récupérer les traces avec un certain niveau, donc j'ai envie de faire un index sur la colonne "niveau", mais est-ce pertinent ? De même pour la date : s'il y a un pb, ils voudront récupérer tous les messages autour d'une certaine date, donc dois-je indexer la colonne "date" ?

[Jaouad]

Tu n'a pas le code applicatif ?

[lalystar]

Tout dépend d'abord de la volumétrie de ta table, si elle est petite, c'est peut être meme pas la peine d'indexer niveau ou date.

Indexer la colonne niveau ne me semble pas intéressant car a mon avis tu n'as que quelques niveaux différents, c'est une colonne peu sélective. Eventuellement candidate pour un index bitmap mais ca m'étonnerais que dans ton cas ca puisse etre intéressant.

Indexer la colonne date me semble intéressant dans le cas d'une recherche par date. Comme la date contient en fait aussi l'heure, il faudra utiliser des requêtes de la forme suivante si tu cherches les alertes d'un jour donné :

Code :

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

1
2
 
dt >= date '2005-08-12' and dt < date '2005-08-13'

(pour pouvoir utiliser l'index)

autrement tu peux créer un index sur trunc(dt)...


Laly.

[_Mac_]

Merci pour vos réponses.

La table risque d'être assez grosse, c'est pour cela que j'envisage de créer des index. Je vais tenter l'index bitmap pour le niveau, ce qui a l'air bien indiqué.

Encore merci

[lalystar]

En général, les indexes bitmap sont plutot pour des tables figées. Il y a un risque d'explosion de la taille du bitmap quand c'est utilité en transactionel... mais à tester, ca ne me semble pas super intéressant a priori, mais a toi de voir.


Laly.

[Jaouad]

En général, les indexes bitmap sont plutot pour des tables figées. Il y a un risque d'explosion de la taille du bitmap quand c'est utilité en transactionel... mais à tester, ca ne me semble pas super intéressant a priori, mais a toi de voir.


Laly.

+1 , même si l'index bitamap est conseillé pour les grosses tables avec des colonnes a faible cardinalité , il est déconseillé lorsqu'il y a bcp d'insertion , update ...
Car à chaque opération il doit être reconstruit entiérement et compressés
Pour plus de détail

[_Mac_]

Vu ce que vous dites, je ne fais pas d'index bitmap : en mode debug, il y aura beaucoup d'insertions, je pense. Est-il intéressant alors, que je fasse un index classique à la place ?

[Jaouad]

Vu ce que vous dites, je ne fais pas d'index bitmap : en mode debug, il y aura beaucoup d'insertions, je pense. Est-il intéressant alors, que je fasse un index classique à la place ?

Oui tu peux essayer

[lalystar]

Vu ce que vous dites, je ne fais pas d'index bitmap : en mode debug, il y aura beaucoup d'insertions, je pense. Est-il intéressant alors, que je fasse un index classique à la place ?

Tout dépend des valeurs que peut prendre cette colonne.

Si tu as deux valeurs et que tu as une répartition 50-50 sur bcp de lignes ca ne me semble pas intéressant.

Si la répartition est de 90-10 alors oui ca peut etre intéressant.


Laly.

[_Mac_]

Autre question : est-ce que les index permettent d'accélérer les requêtes WHERE ... LIKE ?

[orafrance]

oui si les 1° caratères sont connus... LIKE '%... non par contre

[PaulBilou]

Bonsoir à tous,

Si je dis que moins on à d'index mieux on se porte ???
A part les clés étrangères, j'attends la mesure des performances pour créer des index au cas par cas.

Est-ce une bonne démarche ?

Paul

[rouardg]

Bonjour,

Pour moi, c'est une démarche comme une autre : il y a des gens qui partent avec une base surindexée, et d'autres avec une base sousindexée et qui en rajoutent au fur et à mesure des pb rencontrés.

Pour ma part, ma démarche est la suivante :

1 ) faire un MCD (Modèle Conceptuel de Données) et un vrai. Je vois encore trop de bases de données qui n'ont aucun MCD.

Pour ce faire, il faut savoir modéliser correctement et user des entités et des associations.

Au niveau des entités, il faut définir un identifiant (qui sera traduit en clé primaire), et ne pas hésiter à définir d'autres identifiants si l'on en a (lesquels seront traduits en clés alternatives). La définition des ces identifiants permettra alors de générer des contraintes d'intégrités ainsi que des index uniques. Personnellement, j'évite aussi de définir les champs métiers comme PK, préférant largement les définir en tant qu'AK.

D'autre part, il ne faut pas hésiter à définir les colonnes obligatoires quand elles le sont. Cela permet d'une part de donner plus d'informations à l'optimiseur de requêtes, et d'autre part cela évite de générer des systèmes de saisie minimaliste.

Ensuite, au niveau des associations, je me pose la question de savoir dans quel ordre définir cette association. Par exemple, si je dois effecteur une association N-N entre 2 entités A et B, dois-je le faire dans l'ordre A et B, ou B et A ? Pour répondre à cette question, j'utilise en premier le fonctionnel : si les utilisateurs interrogent plutôt les données en spécifiant B, alors l'associaiton est créée dans le sens B-A. Sinon c'est l'inverse. Et si l'on tombe dans le cas de figure où, soit on n'a aucune idée de l'interrogation des données, ou soit on interroge aussi bien les données suivant A ou B, alors je regarde la sélectivité des données, et l'association est créée avec l'entité la plus séléctive en premier.


2 ) ensuite on génère le MPD (Modèle Physique de Données). C'est l'occasion de s'interroger sur 3 points :
a ) la volumètrie et le type de tablespaces à créer,
b ) la structure physique de stockage : dois-je partitionner des tables, utiliser des IOT, mettre 2 tables en cluster, ou bien encore utiliser des vues matérialisées ?
c ) revue des index : on sait que les PK et AK du MCD ont généré des index uniques.

Pour les FK, on a des index non unique. Faut-il en supprimer ? Pour ma part, je supprime ces index si il ne sont pas assez séléctif, et si il ne sont pas nécessaires à des deletes (en cascade ou non) sur les tables mères.

Ensuite, il peut m'arriver de créer des index supplémentaires, car je sais fonctionnellement que telles données de telles tables vont être systématiquement utilisées. De toute manière, on peut toujours tracer les plans d'exécution des requêtes pour vérifier que l'index supplémentaire que l'on a créé est bien utilisé.

Pour finir, on peut aussi revoir le type d'index, en créant soit du BitMap, soit des index basés sur une fonction (si nécéssaire).

En conclusion, je pense que si les bases de données suivaient ce genre de démarche, on aurait une meilleure qualité de la base, et beaucoup moins de pb de performance.

[PaulBilou]

Bonjour à tous,

Rien à ajouter à la démarche de rouardg !
C'est la perfection même.

Paul

[pioupiouprod]

salut,

perso, il m'a été conseillé dans une formation de rester dans une limite de 8 indexes pour une table sous peine de voir les perfs d'accès au enregistrement tomber quand la table est importante. Quid pour vous?

[rouardg]

8 index par table ?

Moi j'aurais tendance à dire que c'est déjà beaucoup. Quand une table a 5 ou 6 index, c'est déjà pas mal.

Maintenant, il n'y a pas de vérité absolue. Car dans certains cas, tu peux avoir une entité qui a pas mal de relations avec d'autres.

Pour te donner un exemple, dans ma base de données où j'ai en gros 200 tables, l'une d'entre elle comporte 11 index (1 index unique de PK, 1 index unique d'AK, et 9 index posés sur des FK).