Discussion :

[arthenius]

Bonjour tout le monde

Voila je vous expose mon cas de conscience

j'ai de grosses table (+4Millions de lignes) dans ces tables j'ai dans les 7-8 foreign key sans aucun index sur ces foreign key(qui pointent vers de petites tables de 10-100 enregistrement), 4-8 index différents qui me sont nécessaire pour faire tourner une panoplie de requete (principalement des procédure stockées / trigger)

Mon souci c'est que lorsque que je tente de delete un enregistrement d'une table enfant(les petites tables), => je reçoit un time out => forcement le serveur parcourt ma grosse table pour voir si par hasard, l'enregistrement que je tente de supprimer serait pas utiliser...

du coup la solution simple efficace et qui marche (puisque je l'ai tester et que c'est conseiller partout sur le net) j'ai rajouter un index sur la foreign key en question ==> plus de time out

Oui mais voila si je met un index pour chaque foreign key de chacune de mes énormes tables, la présence de ces index ne vont-ils pas ralentir de manière significatives mes insert et autre updates sur ces grosses tables (puisque cela fera plus d'index a mettre à jour )??

bref je me pose la question du gain évident sur un delete de child table, par rapport a la perte de temps des mises a jours d'index de grosses tables (qui sont bien évidement beaucoup plus sollicite que les child table) ?

merci par avance de vos retours d'expérience en la matière

[elsuket]

Bonjour,

8 index pour une table c'est beaucoup trop.
Cela indique soit une erreur de conception, soit une gestion des index inappropriée.

Vous pouvez créer des index composites (sur plusieurs colonnes) mais il vous faut pour cela étudier lesquels conviendront le mieux.
Notez qu'en version 2005, SQL Server vous permet de créer des index dont les colonnes ne sont pas des clés de tri au niveau feuille d'un index non-cluster avec la clause INCLUDE.

mais voila si je met un index pour chaque foreign key de chacune de mes énormes tables, la présence de ces index ne vont-ils pas ralentir de manière significatives mes insert et autre updates sur ces grosses tables (puisque cela fera plus d'index a mettre à jour )??

C'est exact, et même sur les DELETE.

bref je me pose la question du gain évident sur un delete de child table, par rapport a la perte de temps des mises a jours d'index de grosses tables (qui sont bien évidement beaucoup plus sollicite que les child table) ?

C'est à vous de voir :

- soit votre table est faiblement modifiée (supposons qu'elle est insérée pendant les périodes de faible activité), et la plupart du temps elle est accédée en lecture seule : vous pouvez alors vous permettre dans une certaine limite d'avoir plusieurs index non-cluster sur cette table,

- soit votre table est beaucoup modifiée, et dans ce cas vous devez réduire le nombre d'index, en les paramétrant avec l'option FILLFACTOR et éventuellement PAD_INDEX (si vous êtes sous SQL Server 2005)

Rappelez-vous que trop d'index tue l'index

@++

[arthenius]

- soit votre table est beaucoup modifiée, et dans ce cas vous devez réduire le nombre d'index, en les paramétrant avec l'option FILLFACTOR et éventuellement PAD_INDEX (si vous êtes sous SQL Server 2005)

Rappelez-vous que trop d'index tue l'index

@++

je suis plutot dans ce cas la puisqu'il s'agit ni plus ni moins de mes tables de detail facture, commande, etc....
bref il va falloir que je verifie ces index
merci pour cet avis