Une vue (matérialisée) pour tout une page ?

Bonjour,

Je crois que c'est une idée folle, mais est-il possible de concevoir qu'une vue (matérialisée) soit plus rapide que 5 appels à la base via php ?

Je m'explique :

Admettons que j'utilise spip. Que les boucles dans un template aillent me chercher mes infos partout où j'en ai besoin pour construire ma page (5 boucles).

N'aurais-je pas intérêt à utiliser une vue qui regrouperait toutes les infos que j'ai besoin d'afficher et qui ne ferait qu'un accès à la BDD au lieu de faire mes appels ?

On "fixe" la valeur initiale grâce au paramètre d'url ou une boucle en amont et tout se déroule en fonction d'elle.

C'est jouable point de vue perf ? Ou je me prends la tête pour rien ?

Merci à vous,

A bientôt,

LeHibou

salut,

Les vues dans mysql ne sont qu'un appel à une requête qui est ré-exécutée à chaque appel à la vue, y a pas une exécution qu'en cas de mise à jour de la table...

donc dans mysql ça évite juste de passer la requête surtout si elle est longue... mais moins optimisé et utile qu'une procédure stockée qui permet d'avoir une interactivité car tu peux faire du paramétrique contrairement à une vue qui ne permet qu'une requête figée...

perso spip et autre environnement du genre, je trouve ça lourd et peu intéressant techniquement... ça rajoute des couches d'interprétation inutiles que tu peux faire plus efficacement en pur php...

comme je dis souvent ce genre de truc qui encapsule un langage (php, java, etc...) ça te complique plus les choses en te promettant un truc hyper paramétrable et en général, l'approche sql est... déplorable en terme de perf...
le truc c'est que ça permet de faire beaucoup de chose en xml (ou autre) sans vraiment programmer...
après c'est un choix...:ccool:

après, la encore une vue implique que tu puisses faire une seule requête...

déjà il serait bon de voir les requêtes et les tables pour voir quoi en faire...
une procédure stockée peut éviter des allers-retours... à voir donc...

Citation:

---

Envoyé par ericd69

salut,

Les vues dans mysql ne sont qu'un appel à une requête qui est ré-exécutée à chaque appel à la vue, y a pas une exécution qu'en cas de mise à jour de la table...

donc dans mysql ça évite juste de passer la requête surtout si elle est longue... mais moins optimisé et utile qu'une procédure stockée qui permet d'avoir une interactivité car tu peux faire du paramétrique contrairement à une vue qui ne permet qu'une requête figée...

---

Les vue matérialisées sont des vues contenant des données physique, ce type de vue est mis a jour selon un paramétrage dans MySQL, elles sont différentes des vues "normal" qui ne sont que des tables existant durant la requête.

dans mysql (voir la doc) tu n'as que 3 modes:

• merge: mysql reformule la requête qui lit la vue en utilisant celle dans la vue
• temptable: mysql génère une table temporaire à partir de la requête dans la vue qui servira le temps de l'exécution de la requête qui lit la vue...
• undefined (par défaut): c'est mysql qui décide lequel des 2 est le plus efficace si on met rien

dans tous les cas on ré-exécute la requête à chaque accès... même si tu as une table temporaire qui est générée sa durée n'est liée qu'au temps d'accès de la requête qui lit la vue (ce qui n'est pas vrai dans les gros sgbd comme oracle ou sql server où la table dure tant que la vue existe et est mise à jour que si les table sous-jacentes sont modifiées, ce qui rend les vus beaucoup plus pratiques et utiles)
de plus, le contenu n'est pas modifiable selon le mode choisi et si les données sont directement obtenues ou non... donc les vues dans mysql ça se discute...
de toute façon les vue ne sont pas très performantes sur des données nombreuses et souvent modifiées, la requête directe sera souvent plus performante...

si tu as 5 requêtes déjà faut les voir et les optimiser, correctement indexer les tables et ensuite si on peut les combiner efficacement...
la super méga requête unique qui fait le café, le lit et le reste, c'est une usine à gaz et pas forcément optimisé du tout

enfin le sql procédural peut éviter la plupart des allers-retours serveur/sql, c'est donc pas les solutions techniques qui manquent :ccool:

Merci de vos réponses.

Quand je pensais aux vues, je pensais simplification.

Et effectivement, admettons que j'aie une table calculée en procédural qui regroupe toutes les informations dont j'ai besoin pour mon affichage, il est là le gain de temps phénoménal : j'aurai tout au plus deux requêtes.

Une pour indiquer quel id il faut charger, une autre qui appelle le reste de la page.

Et comme sql est plus rapide que php à ce petit jeu, je peux peut-être gagner en temps d'exécution..

Non ?

Une vue n'est qu'une requête enregistrée mais qui s'interroge comme une table.

Si tu es capable de faire une seule requête qui rapatrie toutes les infos dont tu as besoin dans ta page pour tous les id susceptibles d'alimenter la page, transforme la ensuite en vue pour l'interroger avec un WHERE id = une_valeur.

Maintenant, si la requête est trop compliquée, comme dit ericd69, ça peut être contre productif et il peut être plus intéressant de passer par une procédure stockée qui va faire le boulot et retourner un jeu de résultat unique en fonction des paramètres passés mais qui exécutera pour cela en interne au SGBD plusieurs requêtes plus rapides que la grosse.

Il faut tester avec un volume de données significatif.