Share
La série MySQL 5 a introduit pas mal de changements. Les déclencheurs et les procédures stockées étaient deux des éléments les plus coûteux. L’introduction de vues est l’un des ajouts les moins connus, du moins en ce qui concerne l’écriture sur le sujet. Bien que, après un rapide coup d'œil aux vues MySQL, vous ne voyiez peut-être pas les avantages évidents, ils sont là si vous les creusez un peu.
"Une vue n'est rien de plus qu'une pseudo table effectuant le travail d'une requête définie."
En bref, le moyen le plus simple d’observer une vue est qu’il s’agit simplement d’une requête stockée imitant une table. Ce n'est rien de plus qu'une pseudo table effectuant le travail d'une requête définie. Il n'ajoute aucune fonctionnalité, telle que la modification de variables, ni ne lance d'autres requêtes lorsque quelque chose d'autre se produit. Vues simplement assis là, gros idiot et heureux de faire ce que vous leur avez dit de faire.
À première vue, cela ne semble pas être un gros problème, mais si vous creusez au-delà de la surface, vous pouvez commencer à voir une partie de la puissance de la vue humble. Je ne vais pas dire que les vues changeront votre vie, mais je vais vous dire qu'elles faciliteront un peu le travail d'interaction avec les bases de données. Ils faciliteront un peu votre travail lorsque vous apportez des modifications de version majeures à votre couche d'interaction. Ils rendront également certaines tâches difficiles, telles que les rapports dynamiques, un peu plus efficaces et un peu plus faciles à utiliser. Je vais prendre un peu plus facile n'importe quel jour de la semaine.
Avec n'importe quoi il y a des compromis.
"Les vues peuvent et vont probablement diminuer vos performances."
Comme je l'ai écrit par le passé, je suis partisan de faire des compromis tant que vous comprenez ce qui est sur la table. Il est plus que probable que quelqu'un contournera ce paragraphe et fera un commentaire selon lequel vous ne devriez jamais utiliser une vue en raison de l'impact négatif sur les performances. Je ne suis pas d'accord. Vous devez utiliser tous les outils de votre boîte à outils, mais quand ils ont un sens. Vous n'utilisez pas de marteau pour enfoncer une vis dans un mur, tout comme vous n'utiliseriez pas de vue lorsque vous avez vraiment besoin d'une table mémoire / tas. Le revers de la médaille est la convivialité du développement pour vos applications. Faites ce choix lorsqu'il est judicieux d'économiser du temps, des efforts et de l'énergie par rapport aux performances que vous pourriez subir. Le développement ne concerne pas uniquement les performances de vos applications, car il existe d'autres considérations telles que l'assistance, la mise sur le marché et la valeur globale de votre temps..
Les outils avec lesquels je travaille dans ce tutoriel sont plutôt standards. J'utilise phpMyAdmin pour l'interaction avec la base de données à des fins d'explication. J'utiliserai également des structures de table très rudimentaires, strictement pour faciliter l'explication. Je ne m'attends pas à ce que ces structures de table soient utilisées dans un environnement de production, je les utilise simplement à titre d'illustration..
Une note supplémentaire. Il n'y a pas de bonne ou de mauvaise façon de nommer une vue. Cependant, je nomme mes vues avec la syntaxe de view_ * primary_table * _ * what_the_view_is_used_for * sauf si je travaille sur des modifications de compatibilité ascendante. Ainsi, si je créais une vue à des fins de génération de rapports statistiques sur ma table salesforce, mon nom de vue serait: view_salesforce_statistical_report. Cela peut être assez long et vous n’avez que 64 caractères avec lesquels travailler, alors gardez cela à l’esprit. Cela fonctionne pour moi et mon style, cela pourrait ne pas fonctionner pour vous.
"Je ne vais pas dire que les vues vont changer votre vie, mais je vais vous dire qu'elles faciliteront un peu le travail d'interaction avec les bases de données. Elles faciliteront votre travail un peu plus lorsque vous apporterez des modifications majeures à la version. votre couche d’interaction. Elles rendront également certaines tâches difficiles, telles que la création de rapports dynamiques, un peu plus efficaces et un peu plus faciles à utiliser. "
Comme je l'ai dit, une vue n'est qu'une requête. Il y a quelques légères configurations que nous devons faire lors de la création d'une vue, discutons-en d'abord. Dans phpMyAdmin, dans la page de tableau "parcourir", vous verrez un lien appelé "Créer une vue".
Si vous cliquez sur ce lien, vous devriez voir quelque chose qui ressemble à ceci:
Ceci, mes amis, est où la magie se produit. Il n’ya pas grand chose à expliquer sur la page, mais examinons rapidement les définitions que nous devons comprendre pour créer une vue..
Premièrement, il y a "Créer une vue" suivi de "OU REMPLACER". Si vous cliquez sur OU REMPLACER, cela fera exactement ce que vous pensez, c'est-à-dire remplacer une vue existante. Le nom des colonnes est le nom des colonnes de votre table. Chacun est séparé par une virgule, il peut donc ressembler à prénom_nom, deuxième_nom, etc. AS est la requête..
Il y a deux autres éléments à expliquer, mais les concepts ne sont pas difficiles. ALGORITHM contient les sélections des tables non définie, de fusion et temporaire. Si vous sélectionnez "Fusionner" lorsqu'il existe une relation un à un, la requête entrante sera combinée à la vue. La table temporaire est moins efficace, mais lorsque vous n'utilisez pas de relation un à un, telle qu'une fonction d'agrégation telle que SUM () ou que vous utilisez certains mots clés tels que GROUP BY ou HAVING ou UNION, vous devez utiliser l'algorithme de table temporaire. Cela dit, vous pouvez faire comme moi et laisser l'algorithme comme "non défini" et MySQL sélectionnera le meilleur algorithme à utiliser..
Enfin, nous avons les options CASCADED CHECK CHECK et LOCAL CHECK. Les options de contrôle indiquent à MySQL de valider la définition de la vue s’il existe une condition dans la requête, telle que WHERE. Si la clause WHERE exclut des données, cela empêchera les mises à jour ou l'insertion de ces lignes où elles devraient être exclues. Le contrôle local traite uniquement de la vue que vous définissez, où CASCADED CHECK est destiné aux vues que vous avez définies à partir d'autres vues. Il sera la cascade du chèque pour ceux aussi.
C'est une vue en quelques mots. Jetons un coup d'oeil à quelques cas d'utilisation pour les voir en action et où ils peuvent aider vos efforts de développement.
Cela m'est arrivé plus souvent que je n'aurais voulu mentionner lorsque j'ai conçu une table à usage unique qui, je pense, n'aura jamais besoin d'être normalisée. Prenons l'exemple présenté précédemment avec quelques enregistrements supplémentaires.
De toute évidence, mes compétences en normalisation laissent à désirer dans cet exemple. Ce que j’aurais probablement dû faire lors de la création de cette table, c’était d’avoir une table distincte pour les adresses, puis d’appeler simplement address_id dans ma table des effectifs de vente. Le problème est que, une fois que je passe à un changement de base de données, je dois remonter dans ma couche d'interaction logique et apporter de nombreuses modifications à la requête. Au lieu de faire autant de travail, pourquoi ne pas laisser une vue venir à la rescousse?.
Commençons par modifier la structure de ma table. Je copie ma structure de table et mes données dans ma nouvelle table, avec les adresses et rend la table saine, par exemple en ajoutant l'adresse id_id et en supprimant la structure inutile:
Ensuite, je dois juste supprimer les colonnes incriminées et rajouter mon adresse_id à ma table des ventes.
Il s’agit d’un changement assez courant que vous apportez de manière semi-régulière, bien que de nature plutôt simpliste. Vous vous rendez compte que vous pouvez normaliser quelque chose grâce à une nouvelle fonctionnalité. Dans ce cas, nous pouvons réutiliser nos adresses pour des clients, ou pour d’autres employés, ou pour tout ce que nous pourrions stocker des adresses. Ce travail n’est pas si difficile, mais en fonction de la réutilisation de votre requête, la recherche de tous les endroits que vous appelez notre ancienne table sales_force peut représenter un changement beaucoup plus important de la portée. En vient une vue.
Au lieu de revenir immédiatement dans notre code et d’attendre un cycle de publication normal, nous pouvons créer une vue pour conserver notre ancienne fonctionnalité. J'ai changé le nom de notre table sales_force en sales_force_normalized:
Nous pouvons maintenant créer notre vue pour maintenir la compatibilité avec les versions antérieures:
Et nous avons notre compatibilité ascendante avec juste le travail supplémentaire de créer une requête qui repose dans MySQL:
Même lorsque j'entre un nouveau vendeur, mon point de vue reflétera le changement:
Et presto:
Environ deux minutes de travail pour maintenir notre compatibilité ascendante avec notre structure de données précédente. Cette méthode présente des inconvénients, en ce sens que vous ne pouvez pas définir d’index sur votre vue, ce qui est important lorsque vous affichez des vues en cascade. De plus, vous devrez toujours modifier vos requêtes pour INSERT, DELETE et UPDATE, mais cela vous épargnera du travail. Vos performances risquent de chuter un peu, mais il n’existe pas de moyen plus simple d’apporter des modifications à la structure de vos données pour faciliter la modification de votre base de code. Vos requêtes dans votre couche logique resteront inchangées car, à leur connaissance, elles consultent la table d'origine..
Maintenant que nous avons notre preuve de concept sous notre ceinture, examinons un autre usage. J'ai créé une autre table pour capturer les données de vente de ma table salesforce et je l'ai remplie avec des informations aléatoires. Cela ressemble à ceci:
C'est un tableau extrêmement simplifié permettant de saisir les ventes de la force de vente à des fins d'illustration. Il y a toujours des choses que nous voulons extraire pour la mesure sur une table comme celle-ci. Je veux probablement connaître le total des ventes. Je voudrais probablement connaître le total des ventes par personne. Je pourrais aussi vouloir connaître le rang de la performance des ventes. Je pouvais écrire des requêtes dans la logique de ma base de données pour exécuter chacune de ces tâches lorsque j'en avais besoin, ou simplement écrire une vue pour récupérer les données si nécessaire. Comme il s’agit d’un tutoriel sur les vues, je suppose que le choix est assez simple à ce stade-ci, quelle tactique adopter.
Commençons par évaluer le total des ventes et d’autres informations pertinentes:
Ce qui nous donne une vue sur:
J'ai également inclus le temps d'interrogation sur celui-ci, car l'examen de 200 enregistrements est extrêmement rapide, mais les performances peuvent varier. Notez que je n'utilise pas les fonctions CHECK car je ne discrimine pas les informations contenues dans une clause WHERE. Maintenant que nous avons ces informations soigneusement emballées, il ne reste plus qu'à construire notre mécanisme de reporting dans notre logique.
Obtenir cette information n'est pas si difficile. Allons un peu plus loin et utilisons une fonction GROUP BY et une fonction de jointure contre salesforce. Encore une fois, j'utilise des requêtes simplifiées pour illustrer. Dans ce cas, nous voulons obtenir les mêmes informations que nous avions sur les ventes totales, mais cette fois ventilées par notre vendeur individuel..
Ce qui nous donne une vue sur:
Encore une fois, très simple en fin de compte pour extraire ces valeurs de votre base de données. Jetons un coup d'oeil à un autre exemple, qui combinera les deux vues. Je veux comparer les totaux à l'individu et nous allons donc créer une vue de deux vues:
Ce qui nous donne une vue sur:
Un autre avantage des vues est qu'elles fournissent un niveau de sécurité supplémentaire à vos applications. Vous n'exposez pas la structure de votre table à votre application. Au lieu de cela, vous exposez quelque chose qui n'existe pas vraiment, à l'exception d'une pseudo table. Je n'appellerais pas une vue une pratique exemplaire et l'utiliserais principalement pour écrire des applications sécurisées, mais je la considérerais comme un avantage supplémentaire..
J'utilise des vues de manière limitée. Les endroits où j'utilise les vues sont illustrés ci-dessus, en particulier dans les mécanismes de rapport de mes applications. Ecrire une requête pour effectuer le gros travail pour moi est beaucoup plus facile que d'écrire la logique autour de requêtes plus difficiles. Je ressens de temps en temps un coup sur mes performances, que l’on a tendance à surmonter en optimisant la structure de données originale. Je n’en ai pas encore un qui mette fin aux performances, mais la journée est jeune. Merci beaucoup d'avoir lu.
Accentsconagua