Les vues MySQL sont-elles plus efficaces que les requêtes complexes ?

Question

J'ai un problème avec les instructions SELECT utilisant plusieurs jointures internes. Mon code est le suivant :

SELECT `movies02`.`id`, `movies02`.`title`,
       `movies03`.`talent`, 
       `movies07`.`character`,
       `movies05`.`genre`
  FROM `movies02`
 INNER JOIN `movies07` ON `movies07`.`movie` = `movies02`.`id`
 INNER JOIN `movies03` ON `movies03`.`id` = `movies07`.`performer`
 INNER JOIN `movies08` ON `movies08`.`genre` = `movies05`.`id`
 INNER JOIN `movies02` ON `movies08`.`movie` = `movies02`.`id`;

Utiliser une INNER JOIN pour obtenir les acteurs du film et les rôles qu'ils ont joués semble fonctionner, mais les deux dernières jointures pour obtenir le type de film ne fonctionnent pas, j'ai donc pensé que je pourrais les écrire dans une vue, puis les combiner. lors de la sortie du résultat, levez-vous. Je me retrouve donc avec trois points de vue. Un pour connaître le genre, les acteurs et les rôles, puis un pour tout mettre en place. La question est : est-ce mieux que d’utiliser une seule grande instruction SELECT et plusieurs connexions ?

J'ai essayé de réécrire la requête plusieurs fois et je l'ai essayée de plusieurs manières

Answer 1

Lorsque vous exécutez une requête impliquant des vues, le planificateur de requêtes de MySQL/MariaDB combine toutes les vues et la requête principale en une seule requête avant de déterminer comment accéder à la table. Par conséquent, les performances sont essentiellement les mêmes lors de l'utilisation de vues, d'expressions communes et/ou de sous-requêtes.

Cela dit, les vues sont un moyen utile d'encapsuler une certaine complexité de requête.

En outre, vous pouvez accorder l'accès à une vue à un sous-ensemble d'utilisateurs de confiance sans leur accorder l'accès aux tables sous-jacentes.

Les inconvénients des vues sont les mêmes que si vous placez une logique d'application dans le système de gestion de base de données plutôt que dans l'application : les mises à jour sont plus délicates et il est plus facile d'oublier de les mettre à jour. (Cette question n'est pas pertinente si vous disposez d'un workflow de mise à jour d'application fiable qui met à jour les vues, les fonctions stockées et les procédures stockées lorsque le code de l'application est mis à jour.)

Cela dit, une bonne façon d'écrire ce type de requête est de commencer par la table contenant les entités "de premier niveau". Dans votre cas, je pense que c'est le film. Utilisez ensuite LEFT JOIN pour rejoindre d’autres tables au lieu d’utiliser INNER JOIN. De cette façon, même si certaines sous-entités (acteur, genre, etc.) manquent, vous pouvez toujours voir le film dans les résultats.

Conseil de pro : Si vous le pouvez, nommez la table en fonction des entités qu'elle contient (film, genre, acteur, etc.) au lieu d'utiliser des noms comme whatever01、whatever02. Il est important de pouvoir examiner la requête et la raisonner, et les noms de tables peuvent faciliter cette tâche.