Discussion :

[Fildz]

Bonjour,

j'ai lu dans ce post http://www.developpez.net/forums/d61...-interet-vues/ et celui ci http://www.developpez.net/forums/d61...es/#post412320
que les vues n'améliorait pas les performances.


A priori je pensais que les SGBD mettaient en cache le résultat du SELECT générant la vue, et regénérait le cache lorsqu'un INSERT, ou un UPDATE ou un DELETE était effectué sur l'une des tables sur laquelle portait la requête.

Ma question est simple, pourquoi les vues n'améliorent-elles pas les performances ?

Autre question, serait-il possible de trouver un SGBD ou d'activer un paramètre dans MySQL pour que le comportement que je viens de décrire soit opérationnel ?

[ionesco]

Une vue est représentée par une requête. MySQL stocke cette requête, et la réexécute à chaque fois que tu veux consulter la vue. Donc deux requêtes seront exécutées, celle qui va renvoyer les lignes concernées par la vue, puis la requête qui va piocher dans ce résultat.

Le comportement que tu décris corresponds aux vues MATERIALISEES, ce que MySQL ne gère pas.

Cependant tu peux implémenter toi même ce que tu cherches. En faisant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE ma_vue_materialisee AS SELECT ........

Et tu rafraichis ma_vue_materialisee comme bon te semble ( toutes les X secondes, via un trigger .....)

[Fildz]

Suite a une petite investigation il apparait que le comportement que j'ai décrit est implémenté (de manière plus exhaustive) par les "tables snapshot" aussi appelé "materialized view". Mysql ne permet pas cette fonctionnalité (http://dev.mysql.com/doc/refman/5.1/en/faqs-views.html), alors qu'oracle si (http://www.labunix.uqam.ca/~lalonde/...es_oracle.html).

Reste la possibilité d'implémenter soit même ce principe (notamment avec les triggers) ont parlerait alors de "Vues concrêtes".

EDIT: Grilled : Merci beaucoup pour les précisions ionesco

[ionesco]

FILDZ il fallait faire BDIA lol .....

[SQLpro]

Reste la possibilité d'implémenter soit même ce principe (notamment avec les triggers) ont parlerait alors de "Vues concrêtes".

Sauf que heureusement ce n'est pas l'implémentation généralement choisit par les éditeurs car cela s'avérerait horriblement couteux. Imaginez ce qu'une vue matérialisée demanderait en recalcul si à chaque INSERT, UPDATE ou DELETE il fallait tout refaire et que les tables sous-jacentes aient un million de ligne (cas courant en ce genre de circonstances ?

En fait les SGBDR travaillent à ce niveau par différence (en particulier SQL Server) sans devoir tout recalculer, mais juste la ou les lignes impactée par l'ordre de mise à jour.
Par exemple si INSERT ou DELETE alors un update des lignes de la vue est effectué. Si UPDATE, alors deux UPDATE (valeurs avant et valeurs après) sont effectués pour les lignes impactées de la vue....

Bref, il y a encore quelques années/hommes de R&D pour MySQL pour développer ce genre de choses... Et quand on sait que cela appartient désormais à Oracle, je doute que cela voit le jour à l'avenir !

A +