PHP|Débutant :: Forums

Saluton,
La réponse est dans la dernière partie de ton post et elle était sous-jacente à cette partie de mon propos

En l'occurrence, sauf à ce que la colonne comptabilisant le nombre de lectures soit elle aussi indexée (pour accélérer un ORDER BY par exemple), l'UPDATE pour incrémentation de cette colonne n'impacterait pas les autres index.
Je l'ai dit, tout est affaire de compromis, ici on devrait peut-être sacrifier la performance du ORDER BY pour accélerer les UPDATE

Bonsoir xTG,

Je vais étendre un peu le sujet pour t'éclairer un peu plus sur le sujet des indexs.
D'un point de vue exploitation d'une base de données, c'est à dire quand on se place au niveau applicatif, je dirais qu'il y a deux types d'index différents. Il y a les indexs de structure et les indexs d'exploitation. Par définition, les indexs de structure, sont des indexs obligatoires qui servent à maintenir la cohérence applicative et que tu ne peux supprimer. Il faut donc faire avec. Je vais revenir après sur ce type d'index. Ce que j'appele les "indexs d'exploitation" correspondent à ceux dont parle Maljuna c'est à dire, les indexs facultatif sur un plan structurel mais qui servent à optimiser les performances de tes requêtes / de ton applicatif.

Comment les indexs structurels se différencient-ils des autres et comment les reconnaître?. Un peu de lecture avec la méthode MERISE : Lire la partie concernant le modèle conceptuel de données (MCD) et le modèle logique des données (MLD)

Prenons par exemple deux tables distinctes

Table Documents
Clé Primaire : id (INT unsigned not null auto_increment)
type_id (CHAR 3 not null)
....

Table Documents_types
id (CHAR 3 not null with primary)
nom varchar (20)

On peut très bien laisser les deux tables en l'état avec pour seul index leur clé primaire sans autre index. Quels sont les conséquences d'un tel choix?
Cela oblige à inclure au niveau du code une fonction de contrôle d'existence de type de document lors de la création ou de la modification d'un enregistrement document au niveau du champ type_id. Si on ne le fait pas, cela autorise la création d'enregistrements orphelins, ici un document dont le type (facture, devis, photo, etc...) est inconnu dans la base de données.
Or ce genre de contrôle doit idéalement toujours être effectué par la base de données elle-même, de façon à ce que la tentative de création d'un enregistrement orphelin génère une erreur MySQL géré par l'applicatif. Cela évite de plus, de rendre le contrôle de gestion de l'applicatif dépendant du choix du language de developpement choisi.
Pour résoudre ce problème, il faut donc rajouter un index avec doublons sur le champ type_id de la table documents et construire ses requêtes en conséquence. Cet index est un index de structure

PS: excuse moi maljuna pour mon choix de sémantique ici sur les types d'indexs qui à juste un but didactique.

Voilou

Dernière modification par Jc (10-08-2010 19:28:23)

Bonjour,

Je t'en prie. Pour revenir à la sémantique éxacte de ce que je viens d'expliquer dans un contexte SQL, nous avons les indexs de contrôle d'intégrité de référence (enregistrements orphelins) avec FOREIGN KEY, et les contraintes de validation avec CHECK.

Concernant MySQL, on peut définir des FOREIGN KEY lors de la création de table MyISAM mais elles ne seront pas prises en compte par le moteur. D'où les performances supérieures aussi. Par contre dans une table au format innoDB, les contraintes de référence sont prises en compte et gérée par le moteur. Par conséquent dans un contexte MyISAM en MySQL, on est obligé d'effectuer les contrôles d'intégrité par référence au niveau applicatif. Mais je recommande de définir des indexs sur ces champs où le contrôle d'intégrité applicatif doit être effectué malgré tout. Pourquoi?
Tout simplement car les contrôles d'intégrité par référence font partie intégrante du cahier des charges applicatif et par conséquent les jointures à ce niveaux au niveau des requêtes dans l'applicatif seront redondants.

Voilà.

Dernière modification par Jc (29-07-2010 10:24:57)