par
sadeq » 15 déc. 2006, 10:09
Pour optimiser en général :
Au niveau de la structure :
Le problème des index:
Car un index unique, avec doublon, clé primaire ou clé étrangère imopse systématiquement un processus de tri et crée un support index supplémentaire dont la taille est équivalente à celles des champs index (le volume étant cette taille multipliée par le nombre d'enregistrements)
Et dans ce cas si t'as un index sur un champ entier de 2 oct dans une table qui contient 100 enregistrements, le volume supplémentaire engendré par l'index est de 200 oct.
En plus, le processus de tri est exécuté à chaque INSERT/Update/DELETE ce qui provoque une réindexation (recalcul du fichier index). Et ça coûte cher. Alors:
- Ne pas déclarer les index (uniques ou boublons) inutils
Pas de clés primaires dans les tables qui servent de relation binaire (ou N'aire) et qui sont donc seulement dépondantes d'autres tables
Pas de clés auto-incrémentées systématiques car ceci engendre un calcul supplémentaire en plus du tri
Utiliser des clés primaires de type numérique (entier le moins long possible) car le tri des entiers est simple et leurs petite taille diminue la taille totale de l'index
Le problème de taille et volume
En plus du problème d'index qui influent sur le volume de la table, le choix des types des champs est important car un type implique une taille en oct. Il faut alors faire le bon choix du nombre et du type des champs à déclarer dans la table et bien sûr ne pas déclarer de champs calculés car les requêtes sont, en autres, faites pour ça.
Le problème de la redondance de déclaration d'un champ
La redondance de définition est un problème qui influt sur le volume d'une table et sur la cohérence des mêmes natures de données existantes dans plusieurs tables.
Si un champ peut contenir plusieurs mêmes valeurs et que ses valeurs sont un critère de regroupement alors sa définition doit être effectuée une fois dans la base de données et partagée entre les tables et c'est le fondement même du modèle relationnel.
Exemple:
le champ "situation_familiale" ne peut avoir pour un enregistrement qu'une des valeurs : célibataire, marié(e), divorcé(e) ou veuf(ve)
Mais puisque ces valeurs vont se multiplier par le nombre d'enregistrements de la table, il vaudrait mieux les coder pour diminuer le volume de la table.
En les codant : c, m, d, v on gagne plusieurs oct et en même temps pour ne pas perdre leur signification il faut définir la situation familiale une seule fois dans une table séparée. Définition qui redonne aux codes choisis leur signification tout en gardant le lien entre la table "situation familiale" et celles qui doivent utiliser un champ "situation_familiale"
La situation familiale ainsi définie devient une définition de champ générale à la base et donc réutilisable par plusieurs tables. Si une table a besoin donc du champ "situation_familiale" elle se met en relation avec sa table de définition. Ce qui élimine l'effet négatif de la redondance mais pas la redondance elle même.
La redondance peut être aussi transitive en déclarant des champs pouvant être calculés à partir d'autres sous prétexte de rendre l'accès rapide aux calcul. En effet, l'effet négatif d'une telle redondance est double : le volume de la table augmente et les calculs ne sont pas à jour à moins d'exécuter deux requêtes de recalcul (Select calcul+Update).
Par exemple
dans la table panier d'articles, si on met des champs "total ht" , "montant tva" et "total ttc" c'est une redondance car les 3 champs peuvent être calculés par une requête SELECT à partir des 2 champs "prix de l'article" et "quantité commandée"
Au niveau des enregistrements:
Il faut de temps en temps sauvegarder le contenu des tables et effectuer une réindexation totale, bref "le ménage"
Pour les tables lourdes contenant énormément d'enregistrements il faut penser les partitionner en clones où on peut subdiviser le contenu lourd en plusieurs parties lègères. Cette procédure peut être effectuée par des requêtes.
