[Conception] Performances : intérêt des vues ?

Dans le cas où il y ait des pros MySQL qui trainent sur ce forum je tente un double post. Pas taper :ave: !

Citation:

---

Bonjour,

J'ai des gros soucis de perf sur un select avec pleins de tables et les index qui faut et les join qui vont bien.

Je me suis dis que pour optimiser le tout je pouvais passer par les vues mais je n'arrive pas à trouver d'infos sur le fait que MySQL optimise ou pas ces vues, donc je ne sais pas si c'est une bonne idée...

Des avis ?

Merci d'avance.

---

Salut,

Je ne suis pas un expert MySQL, mais j'ai l'impression que les vues ne sont rien de plus qu'une matérialisation d'une requête particulière, et donc au niveau performance je serais étonné de constater une différence par rapport à la même requête lancée "en dur".

Le problème n'est pas d'avoir une vue qui optimise ou pas la requête, mais d'optimiser la requête elle même. Pour ça, il y a plusieurs choses dont il faut s'assurer :
- Avoir un modèle bien indexé, avec des indexs idealement de type Integer, car ça accèlere grandement le traitement.
- Banir les jointures sur des colonnes non indexées

Après je ne connais pas spécifiquement ton modèle, pourquoi une necessité de faire une requête aussi "complexe" au niveau des jointures ? Peux-tu en donner un exemple ?

Tu sais pas ce que tu fais en demandant cette requête

Code:

---

1 2 3 4 5

SELECT agl.group_artifact_id,agl.name,agl.group_id,g.group_name, a.summary, a.artifact_id, a.severity, (a.submitted_by=241) as submitter, MAX(afv.valueInt=241) as assignee FROM artifact a, artifact_group_list agl, artifact_field af, artifact_field_value afv, groups g WHERE agl.group_id = g.group_id AND af.group_artifact_id = agl.group_artifact_id AND agl.status = 'A' AND g.status = 'A' AND (af.field_name = 'assigned_to' OR af.field_name = 'multi_assigned_to') AND af.field_id = afv.field_id AND (afv.valueInt=241 OR a.submitted_by=241) AND a.group_artifact_id = agl.group_artifact_id AND a.artifact_id = afv.artifact_id AND a.status_id <> 3 GROUP BY a.artifact_id ORDER BY g.group_name, agl.name;

---

Les index sont correctement positionnés, le seul gros soucis c'est le OR avec les test de varchar(255)... :arf:

tu essayes de faire un jeu de role en php basé sur l'intégralité des regles de role master?

A ce niveau c'est ptet au nivo de la conception de la base de donnée qu'une optimisation est envisageable?

Bon courage

Citation:

---

Envoyé par etarip

tu essayes de faire un jeu de role en php basé sur l'intégralité des regles de role master?

---

C'est presque ça mais tu en est loin :)

Citation:

---

Envoyé par etarip

A ce niveau c'est ptet au nivo de la conception de la base de donnée qu'une optimisation est envisageable?

---

Je pense pas, systeme complexe, schéma bd complexe, je parle meme pas du code php derrière !

Citation:

---

Envoyé par etarip

Bon courage

---

Merci :triste:

Les tests en VARCHAR sont très lents, voila ce que je ferais si j'étais toi :

J'externaliserai chaque champ libellé êtant voué à être requêté, par exemple ton champs statut, ou field_name.

Ensuite, apparement dans la logique de ton application, tu as besoin de regrouper certaines informations entre elle : pour ça, rien de mieux que de faire un système hierarchique ( un peu comme un modèle objet à base d'héritage ) qui te permettrait du coup au lieu de faire un OR, de faire directement une requête sur une "famile d'objets" qui répondent à ton besoin.

Citation:

---

Envoyé par KiLVaiDeN

Ensuite, apparement dans la logique de ton application, tu as besoin de regrouper certaines informations entre elle : pour ça, rien de mieux que de faire un système hierarchique ( un peu comme un modèle objet à base d'héritage ) qui te permettrait du coup au lieu de faire un OR, de faire directement une requête sur une "famile d'objets" qui répondent à ton besoin.

---

Tu peux développer et/ou donner un ch'tit exemple ?

Oui, par exemple imaginons un tel modèle de départ :

Fruits
id_fruit
nom_fruit

Panier
id_panier

Panier_Fruit
id_panier
id_fruit
quantité


Je souhaite faire une requête sur mon panier, pour obtenir les fruits rouges.
Au lieu de faire un peu ce que tu fais dans ta requête ( af.field_name = 'assigned_to' OR af.field_name = 'multi_assigned_to' ) ceci :

where nom_fruit = 'fraise' OR nom_fruit='cerise'

Tu pourrais améliorer ton modèle, en ajoutant une "famille" fruit rouge :

Famille_Fruit
id_famille
nom_famille

Fruits
id_fruit
id_famille
nom_fruit

Ta requête deviendrait alors :

where id_famille = 1

En ajoutant les bonnes clés étrangères et une bonne indexation, ça améliorerait _BEAUCOUP_ le temps de réponse :)
J'ai prit un exemple simpliste, car je ne comprend pas bien ton modèle, sinon j'aurais peut-être utiliser les termes de ton modèle directement.

tu as concu ta base de donnée en freestyle ou t passé par une méthode comme merise ou uml?

Citation:

---

Envoyé par KiLVaiDeN

Oui, par exemple imaginons un tel modèle de départ :

[...]

En ajoutant les bonnes clés étrangères et une bonne indexation, ça améliorerait _BEAUCOUP_ le temps de réponse :)
J'ai prit un exemple simpliste, car je ne comprend pas bien ton modèle, sinon j'aurais peut-être utiliser les termes de ton modèle directement.

---

T'ain, t'es un chef :ccool: j'ai compris ton exemple ! :D mais malheureusement difficilement adaptable à ma situation car on ne gère pas de fruits :(

Citation:

---

Envoyé par etarip

tu as concu ta base de donnée en freestyle ou t passé par une méthode comme merise ou uml?

---

Réponse du gars qui arrive en cours de projet : c'est pas moi qui a designé le bazar.
Mais à vue de pied c'est pas mal fichu et il y a peu de choses à redire... hormis cette requête. Bon ben merci du coup de main sinon j'ai plus d'infos sur le forum MySQL (ils ont du finir de manger :) ) http://www.developpez.net/forums/vie....php?p=2308931

Sujet résolu pour moi : pas de vues !

Les vues n'ont rien à voir avec les performances.

une vue = un select

donc faire un select dans une vue c'est faire un select de select.

en fait cela n'influ pas sur les perfs.

une vue est intéressante lorsque tu dois remonter une info toujours de la même façon.

par exemple j'ai une table alerte et une autre type_alerte. (alert contenant un id de type d'alerte)

lorsque je remonte une alerte je veux aussi systématiquement son type, non pas l'id de son type mais le type lui même

Code:

---

1 2	SELECT * FROM alerte;

---

me donne les alertes mais je n'ai pas leur type.

Code:

---

1 2 3

SELECT * FROM alerte INNER JOIN type_alerte USING (typ_id);

---

me donne les alertes avec leur type.

si je veux une seule alerte je dois faire :

Code:

---

1 2 3 4

SELECT * FROM alerte INNER JOIN type_alerte USING (typ_id) WHERE ale_id=45;

---

pour toute les requêtes je suis obligé de faire la jointure.

utiliser une vue va me permetre de travailler avec des alertes typées.

Code:

---

1 2 3 4

CREATE VIEW alerte_typee AS SELECT * FROM alerte INNER JOIN type_alerte USING (typ_id);

---

pour obtenir l'alerte 45 comme ci dessus je n'ai plus qu'à faire

Code:

---

1 2 3

SELECT * FROM alerte_typee WHERE ale_id=45;

---

Les vues sont bien pratique dans ce genre de cas. ou lorsqu'une même table sert à garder différent objets dont la structure est identique mais pas la sémantique.

par exemple je fait au près de mes client des interventions in situe, des formation, des audit etc.

toutes ses actions ont les mêmes champs. mais j'ai besoin de gérer les différents type d'actions indépendament car la sémantique associé est différente. il serait dommage de créer plusieurs table avec la même structure.

je fait donc une table action et autant de vue que de type d'actions je peux donc manipuler les actions comme je voulais mais les stoquer en une seule table.


si vous programmé en objet vous pouves avec ce principe stocker vos objets dans une table unique. tous mes objets de classe intervention, formation, audit dérive de la classe actions pour les récupérer je pioche dans la vue corespondante.

A+JYT