bonjour,
je débute dans les sgbd et j'aurai besoins de vos conseil pour créer un index sur mesure par rapport a ce que je voudrais faire.
 
le contexte: un hopital, une base oracle9i, un logiciel de reporting: cognos reportnet, le rapport sur lequel je travaille actuellement permet aux chefs de service de visualiser les honoraires de leur service via une page d'invite ou ils peuvent rentrer la date de prestation de l'acte médical, et le type d'acte.
 
une version simplifiée de ma table serait:
WRK_FHM(
numéro_du_médecin,
numéro_de_compte_de_facturation,
date_de_prestation,
numéro_de_la_prestation,
montant,
nombre_de_prestation)
 
- numéro du médecin se retrouvera obligatoirement dans le where du sql.
- numéro_de_compte_de_facturation s'y retrouvera parfois, quand par exemple un médecin a deux spécialités.
- date de prestation s'y retrouvera souvent, les médecins choisiront probablement les 3 derniers mois en cours.
- numéro de la prestation s'y retrouvera assez souvent également.
 
que me conseillez vous? de creer un index sur les quatres champs, dans l'ordre de leur fréquence d'utilisation?
est il bon d'en creer plusieurs en intervetissant l'ordre?
 
 
j'ai une autre question au passage, j'ai plusieurs champs qui sont en numérique et qui ne feront jamais plus que x chiffres, je les ai donc créé en number(x), y a t'il des moments ou c'est déconseillé ou est ce la bonne marche a suivre?
 
merci de votre aide et de vos conseils

Pour ton index, c'est plutôt en fonction du contenu de la table qu'il faut le créer.
 
Si c'est une table d'informations sur les médecins, un index sur le numéro_du_médecin est approprié.
Si c'est une table liant un numéro_du_médecin à un autre élément (numéro_de_la_prestation apparemment, mais en même temps je comprends pas trop ce que vient faire le nombre_de_prestation du coup ...), alors un index sur ces 2 champs est approprié.
 
De toute façon, si au final le numéro_du_médecin est dans toutes les requêtes, et que les autres critères sont "annexes" (et que la table, pour un même médecin, contient peu de lignes), alors un index sur le numéro_du_médecin suffit, et sera toujours utilisé. Mais pour des raisons d'intégrité de la table, il faut peut-être que le couple médecin / prestation soit unique, dans ce cas, crée un index unique sur ces 2 champs.

en fait c'est une table reprenant tous les éléments de facturation, en fait un enregistrement correspond a:
 
tel type d'acte médical a été effectué a telle date de prestation, par un médecin, facturé sur un compte en banque.
le montant et le nombre de prestation sont des faits.
Pour les contraintes d'intégrité il y a une clé primaire sur le numéro de facture, mais il ne devrait jamais intervenir dans le sql pour ce rapport.
 
il y a plus de champs mais ils ne devraient pas intervenir dans le where, la table fait +/- 7.000.000 d'enregistrements.
 
je ne sais pas si ca peut t'aider mais il y a 800 médecins différents dans la table, 3200 type d'acte médical, 600 numéro de compte en banque, 1000 date de prestation.
 
merci pour ton aide en tout cas.
en cherchant sur le net j'ai trouvé des références a sql trace utility qui pourrait m'aider, si vous avez des conseils a ce sujet

D'après ce que tu dis, la logique serait de créer un index sur le médecin, la date de prestation et le type de prestation. Le numéro de compte est simplement une info de la table, pas vraiment un identifiant.
 
Une fois l'index créé, tu peux écrire tes requêtes et t'assurer qu'elles utilisent bien des index en regardant les 'explain plan' (je te laisse trouver la syntaxe sql qui permet d'afficher l'explain plan).

en fait le numéro de compte n'est pas toujours le meme pour un médecin, par exemple si un médecin travaille en cardio et en soins intensifs il y aura deux numéros de compte. et donc si je dois faire un rapport uniquement pour la cardiologie je vais filtrer par rapport a ca.
 
je n'ecris pas vraiment le sql complet, en fait cela se fait a deux niveaux dans le logiciel de rapport, d'un cote je filtre dans la couche de métadonnée, c'est la ou je vais explicitement filtrer en sql par rapport au numéro de médecin et de compte pour que le médecin n'ait acces que aux données de son service;
d'un autre coté au moment de l'éxécution du rapport le médecin pourra choisir des fourchettes de date et de type de prestation.
 
je vais regarder du coté des 'explain plan' merci pour le tuyau.

Perso, je te conseille de faire plusieurs index.
 
Demande-toi si :
 
-> Quand le médecin spécifie la date, spécifie-t-il aussi le numéro d'intervention ? Si non, alors il y a un index contenant la date, et un autre contenant le numéro d'intervention.
Idem pour la spécialité.
 
A partir de là, tu devrais avec 4 ou 5 index.
 
Tips: pour ce qui est de la spécialité, lorsqu'elle n'est pas spécifiée, je te conseille grandement de le récupérer quand même. Rajoute pour ça une jointure vers une table de référence "numéro médecin / spécialités du médecin".
 
Ca te permettra de spécifier dans tous les cas le numéro de spécialité dans ta requête.

merci de ta réponse arjuna.
 
j'utilisais deja une table avec les types de prestation par service mais je ne m'en servais pas explicitement dans le sql, je m'en servais pour qu'ils puissent sélectionner leurs codes dans l'invite de rapport.
 
au niveau des index, disons que j'ai les champs A,B,C,D;
le champ A sera repris dans le where de toutes les requetes mais a 50% il sera le seul élément de la condition, les champs B et C n'interviendront que 30% du temps, et le D ne sera repris que si B et C ne le sont pas.
 
si je fais ces index
IND_A
IND_D
IND_ABC
IND_AD
est ce que oracle(ou un autre rdbms) sera capable de choisir le meilleur index en fonction de la condition ou bien je risque des contre-performance si je m'y prend mal.
donc dans le cas ou j'ai une requete avec A et D, quel index utilisera t'il?
et une requete avec seulement A?
 
merci de votre aide en tout cas, je sens que j'avance

Je te conseille donc les index suivants :
 
idx1 (A)
idx2 (A, B, C)
idx3 (A, D)
 
Oui, Oracle (et n'importe quel SGBD) est capable de choisir l'index le plus performant pour une requête donnée. Sur les requêtes vraiment très complexes, il faut cependant parfois l'aider avec des "hints" (syntaxe à la con forçant l'optimiseur d'Oracle à faire des actions précises) mais dans ton cas, ce ne sera pas le cas.
 
Avec mon exemple, si tu fais un critère uniquement sur A, il va utiliser idx1, et s'il y a A et D, alors il utilisera idx3.
 
Si tu utilises A et B, mais pas C, alors il utilisera au choix idx1 ou idx2 selon si idx2 est suffisament discriminant pour la valeur de B (c'est généralement le cas )