Deadlock et clés étrangères

[Sdev666]

Bonjour,

Nous travaillons avec une base Oracle 10g et nous avons régulièrement des problèmes de deadlock. L'origine du problème est l'absence d'index sur les clés étrangères des tables.

Nous avons donc deux solutions pour régler cela :
- ajouter des index sur les clés étrangères de nos tables
ou - supprimer la notion de clé étrangère dans notre base

La première solution semble la plus sûre et la plus "intuitive", mais l'équipe dont je fais partie semble privilégier la seconde. Les arguments sont que :
1- un certain nombre de progiciels très connus n utilisent pas les clés étrangères et fonctionnent
2- l'ajout d'index ajouterait une couche au système, or en général moins on a d'élément dans un système (plus le système est simple) et meilleur sont les performances.

Pour le point 1, j'ai fait le même constat pour un progiciel particulier, mais je n'ai pas assez d'exemples pour me faire une idée.

Pour le point 2, les index contribuent aussi à améliorer les performances des requêtes et ils font parti des fonctions de base d'Oracle, donc l'argument ne me semble pas suffisant.

Pourriez-vous apporter des éléments (dans un sens ou dans l'autre) pour choisir la meilleur solution ?

Merci de vos réponses.

[Yorglaa]

à mon avis, se passer de clefs étrangères est une erreur dans la plupart des cas...

Les FK sont un moyen de garantir l'intégrité relationnelle des données, donc s'en passer implique de risquer des données incohérentes, à moins de programmer toute cette logique d'intégrité du coté client (client lourd) ou middle tier (3 tiers).

d'où ma question suivante : pourquoi réinventer la roue ?
Oracle propose en natif de gérer ces règles d'intégrité, alors pourquoi les reprogrammer "à la main" dans son propre logiciel ?

outre le risque d'erreur, de la masse de test "dans tous les sens" que ça implique, etc... il ne faut pas oublier q'une DB ça "s'attaque" aussi par d'autres outils qe le(s) logiciel(s) client(s).

je pense tout particulièrement aux outils de gestion et/ou de Dev (Toad, SQLPlus, etc...). et là, plus acune règle d'intégrité ne sera appliquée si un script malencontreux venait à faire des bêtises...

ensuite de ça, les index sont clairement là pour aider aux performances... et pas seulement pour faire les locks appropriés lors d'opérations DML.
donc lorsque ta DB, après 10 d'exploitation, contient plusieurs dizaines de GB de données mais pas d'index, ça va être coton pour donner des temps de réponses corrects aux applis qui vont s'y connecter.

enfin ce n'est que mon avis !

[Sdev666]

Merci Yorglaa.
Quelqu'un d'autre a-t-il un avis sur la question ?

[7gyY9w1ZY6ySRgPeaefZ]

Je partage l'avis de Yorglaa.
Autant assuré l'intégrité de la bd dans la bd au lieu de faire confiance aux autres... Et puis, les indexes optimisent les requétes.

[Sdev666]

Personne n'a d'avis sur le fonctionnement des progiciel ?

[orafrance]

Envoyé par Sdev666

La première solution semble la plus sûre et la plus "intuitive", mais l'équipe dont je fais partie semble privilégier la seconde. Les arguments sont que :
1- un certain nombre de progiciels très connus n utilisent pas les clés étrangères et fonctionnent
2- l'ajout d'index ajouterait une couche au système, or en général moins on a d'élément dans un système (plus le système est simple) et meilleur sont les performances.

Ils sont un peu grave dans ton équipe... tout le monde fait n'importe quoi alors on y va

Beaucoup de progiciel se passent des clés étrangères pour améliorer la portabilité, tous les SGBD étant à l'époque de leur conception pas relationnelle. MAIS il y a des contre-exemples, et pas des moindres notamment avec OeBS : Oracle E-Businesse Suite, l'ERP d'Oracle.

Pas d'index = meilleures perfs, c'est la meilleur celle-là

Il faut créer les indexes, point... supprimer les FK et les indexes ça rime à rien... faut pas utiliser Oracle dans ce cas, des fichiers plats feront très bien l'affaire

[farenheiit]

Pas d'index = meilleures perfs, c'est la meilleur celle-là

Moi ça ne me choque pas tant que ça. Parfois quand la table est mise à jour de manière très fréquente (dans un system OLTP) il est préférable de ne pas créer d'index => c'est un compromis à faire entre accélerer les select et ralentir les delete/update.

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par farenheiit

Moi ça ne me choque pas tant que ça. Parfois quand la table est mise à jour de manière très fréquente (dans un system OLTP) il est préférable de ne pas créer d'index => c'est un compromis à faire entre accélerer les select et ralentir les delete/update.

C'est un cas particulier et alors, il faut faire quelques choses dans la bd pour ça et faire du tuning des requêtes.
Supprimmer tous les indexes parce qu'il existe des requetes pas optimales revient à utiliser un bazooka pour tuer une mouche.

[farenheiit]

Envoyé par Jerome_Mtl

C'est un cas particulier et alors, il faut faire quelques choses dans la bd pour ça et faire du tuning des requêtes.
Supprimmer tous les indexes parce qu'il existe des requetes pas optimales revient à utiliser un bazooka pour tuer une mouche.

tout à fait d'accord

[orafrance]

Envoyé par farenheiit

Moi ça ne me choque pas tant que ça. Parfois quand la table est mise à jour de manière très fréquente (dans un system OLTP) il est préférable de ne pas créer d'index => c'est un compromis à faire entre accélerer les select et ralentir les delete/update.

Qu'on ne mette pas d'index sur certaines petites tables ou si il y a plus de mises à jour que de sélection pourquoi pas... mais aucun index sur la totalité de la base c'est n'importe quoi sauf cas très particulier

[lmartin]

C'est assez bizarre de penser qu'on améliore les perfs en mettant toute la logique relationnelle dans le code applicatif plutôt que dans le système.

Sans parler du risque supporté en cas d'erreur dans le développement d'une évolution.