Nos tables contiennent très peu de données, par rapport à la réalité. Les applications moyennes classiques exploitent des bases
de données dont les tables peuvent compter des centaines de milliers, voire des millions de lignes. Le gain de performance
permis par les vues matérialisées, et les index, sera encore plus visible sur de telles bases.
Cependant, toutes les vues ne sont pas intéressantes à matérialiser. De manière générale, une vue contenant des fonctions
d'agrégation, des regroupements, et qui donc devra utiliser l'algorithme TEMPTABLE, est une bonne candidate.
Mais il faut également prendre en compte le coût de la mise à jour de la vue matérialisée.
S'il s'agit d'une vue qui doit être constamment à jour, et qui utiliserait donc des triggers, il ne sera sans doute pas intéressant de
la matérialiser si les données sur laquelle elle s'appuie sont souvent modifiées, car le gain de performance pour les requêtes de
sélection sur la vue ne compenserait pas le coût des mises à jour de celle-ci.
Par ailleurs, certaines vues ne nécessitent pas qu'on leur consacre une table entière. Ainsi, la vue V_Nombre_espece peut être
matérialisée simplement en ajoutant une colonne à la table Espece. Cette colonne peut alors être tenue à jour avec des triggers
sur Animal (comme on le fait avec la colonne Animal.disponible).
Comme souvent, il faut donc bien choisir au cas par cas, peser le pour et le contre et réfléchir à toutes les implications quant au
choix des vues à matérialiser.
En résumé
Une vue matérialisée est un objet qui stocke le résultat d'une requête SELECT, c'est donc la matérialisation d'une vue.
MySQL n'implémente pas les vues matérialisées, contrairement à certains SGBD.
On utilise de simples tables comme vues matérialisées, que l'on met à jour grâce à une procédure stockée, ou à des
triggers.
Les vues matérialisées peuvent permettre de substantiels gains de performance.
Il est important de bien comprendre les caractéristiques, ainsi que les avantages et inconvénients des vues, tables temporaires et
vues matérialisées afin de les utiliser à bon escient.
Voici une conclusion générale (et simplifiée) sur l'usage de ces trois concepts.
Les vues ne permettent pas de gagner en performance. Elle fournissent juste une interface, qui peut permettre de gérer
les accès des utilisateurs ou de simplifier les requêtes par exemple.
Les tables temporaires servent lorsque, ponctuellement, on doit faire un traitement sur un set de données particulier,
pour faire des tests ou des statistiques par exemple.
Les vues matérialisées permettent de stocker des données sélectionnées ou calculées à partir d'autres tables. Elles
permettent de gagner en performance dans le cas où ces données nécessitent de longs calculs, mais ne changent pas
trop souvent (attention à l'équilibre coût du calcul sans la vue matérialisée et coût de la mise à jour de la vue
matérialisée).
Partie 6 : Au-delà des tables classiques : vues, tables temporaires et vues matérialisées
373/414
www.openclassrooms.com
de données dont les tables peuvent compter des centaines de milliers, voire des millions de lignes. Le gain de performance
permis par les vues matérialisées, et les index, sera encore plus visible sur de telles bases.
Cependant, toutes les vues ne sont pas intéressantes à matérialiser. De manière générale, une vue contenant des fonctions
d'agrégation, des regroupements, et qui donc devra utiliser l'algorithme TEMPTABLE, est une bonne candidate.
Mais il faut également prendre en compte le coût de la mise à jour de la vue matérialisée.
S'il s'agit d'une vue qui doit être constamment à jour, et qui utiliserait donc des triggers, il ne sera sans doute pas intéressant de
la matérialiser si les données sur laquelle elle s'appuie sont souvent modifiées, car le gain de performance pour les requêtes de
sélection sur la vue ne compenserait pas le coût des mises à jour de celle-ci.
Par ailleurs, certaines vues ne nécessitent pas qu'on leur consacre une table entière. Ainsi, la vue V_Nombre_espece peut être
matérialisée simplement en ajoutant une colonne à la table Espece. Cette colonne peut alors être tenue à jour avec des triggers
sur Animal (comme on le fait avec la colonne Animal.disponible).
Comme souvent, il faut donc bien choisir au cas par cas, peser le pour et le contre et réfléchir à toutes les implications quant au
choix des vues à matérialiser.
En résumé
Une vue matérialisée est un objet qui stocke le résultat d'une requête SELECT, c'est donc la matérialisation d'une vue.
MySQL n'implémente pas les vues matérialisées, contrairement à certains SGBD.
On utilise de simples tables comme vues matérialisées, que l'on met à jour grâce à une procédure stockée, ou à des
triggers.
Les vues matérialisées peuvent permettre de substantiels gains de performance.
Il est important de bien comprendre les caractéristiques, ainsi que les avantages et inconvénients des vues, tables temporaires et
vues matérialisées afin de les utiliser à bon escient.
Voici une conclusion générale (et simplifiée) sur l'usage de ces trois concepts.
Les vues ne permettent pas de gagner en performance. Elle fournissent juste une interface, qui peut permettre de gérer
les accès des utilisateurs ou de simplifier les requêtes par exemple.
Les tables temporaires servent lorsque, ponctuellement, on doit faire un traitement sur un set de données particulier,
pour faire des tests ou des statistiques par exemple.
Les vues matérialisées permettent de stocker des données sélectionnées ou calculées à partir d'autres tables. Elles
permettent de gagner en performance dans le cas où ces données nécessitent de longs calculs, mais ne changent pas
trop souvent (attention à l'équilibre coût du calcul sans la vue matérialisée et coût de la mise à jour de la vue
matérialisée).
Partie 6 : Au-delà des tables classiques : vues, tables temporaires et vues matérialisées
373/414
www.openclassrooms.com