MySQL: vues vs procédures stockées
depuis que MySQL a commencé à supporter les procédures stockées, Je ne les ai jamais vraiment utilisées. En partie parce que je ne suis pas un grand auteur de requêtes, en partie parce que je travaille souvent avec les AD qui font ces choix pour moi, en partie parce que je suis à l'aise avec ce que je sais.
en ce qui concerne la sélection des données, en particulier lorsque l'on considère un select qui est essentiellement une désormalisation (jointures) et agrégat (avg ou max, sous-séries w/counts, etc) sélection des données, Quel est le bon choix dans MySQL 5.x? Une vue? Ou une procédure stockée?
vues Je suis à l'aise avec - vous savez ce que votre requête SELECT est censé ressembler alors vous créez juste cela, assurez-vous qu'il indexé et ce que, puis juste faire un CREATE VIEW [View] AS SELECT [...]. Puis, dans mon application, je traite la vue comme un tableau en lecture seule-il représente une version désormalisée de mes données normalisées.
Quels sont les inconvénients ici - s'il y en a? Et ce qui changerait (gains ou pertes) si je déplaçais cette même déclaration SELECT dans une procédure stockée?
j'espère trouver de bonnes informations' sous le capot ' qui ont été difficiles à trouver en googlant ce sujet, mais je suis vraiment heureux de tous les commentaires et réponses.
4 réponses
à mon avis, les procédures stockées ne devraient être utilisées que pour la manipulation de données lorsque la même routine doit être utilisée entre plusieurs applications différentes ou pour L'ETL entre bases de données ou tables, rien de plus. Fondamentalement, faire autant en code que vous pouvez jusqu'à ce que vous exécutez dans le principe sec ou ce que vous faites est tout simplement déplacer des données d'un endroit à un autre dans le DB.
les vues peuvent être utilisées pour fournir une "vue" alternative ou simplifiée des données. En tant que tel, j'irais avec une vue car vous ne manipulez pas vraiment les données autant que de trouver une méthode différente de l'afficher.
j'utilise les vues pour la désormalisation ou le formatage de sortie et les procédures stockées pour le filtrage et la manipulation de données (choses qui nécessitent des entrées de paramètre) ou l'itération (curseurs).
j'accède souvent à une vue à l'intérieur d'une procédure stockée lorsque la dénormalisation et le filtrage sont nécessaires.
Pas sûr si c'est un choix. Les procédures stockées peuvent faire une grande variété de choses que les vues auraient du mal (penser à peupler les données dans la table temp puis à lancer le curseur sur elle et ensuite faire l'agrégation et retourner un ensemble de résultats).
D'un autre côté, les vues peuvent cacher des droits sql / access complexes et présenter une vue modifiée du schéma.
je pense que les deux ont une place dans le schéma des choses et les deux sont utiles pour un schéma réussi application.
une chose à noter, au moins avec la vue mysql les résultats sont stockés dans une table temporaire et contrairement à la plupart des moteurs de base de données décents cette table n'est pas indexée, donc si l'utilisation pour simplifier les requêtes, la vue sont grands quand votre programme va saisir tous les résultats de la vue, cependant si votre Puis recherche les résultats de cette vue, sur la base de paramètres, il est incroyablement lent, surtout s'Il ya des millions d'enregistrements à passer au crible et encore pire si la vue est construite sur le dessus d'autres vues et ainsi de suite.
une procédure stockée cependant vous pouvez passer ces paramètres de recherche et lancer la requête directement contre les tables de soulignement (indexées). l'inconvénient est que les résultats devront être récupérés chaque fois que la procédure est exécutée, ce qui peut également se produire avec une vue en fonction de la configuration du serveur.
donc en gros si votre utilisant une vue de tenter de minimiser le nombre de résultats (si vous devez chercher) sinon utiliser une procédure stockée.