Les vues MySQL peuvent-elles accepter les paramètres de filtrage dynamique des données ?

Les paramètres peuvent-ils être incorporés dans les vues MySQL ?

La requête initiale tente de créer une vue avec un paramètre, mais MySQL l'interdit. La solution de contournement présentée consiste à créer une fonction pour récupérer la valeur du paramètre, puis à l'incorporer dans la définition de la vue. Cependant, cette approche est jugée insatisfaisante en raison de sa complexité et de son manque d'élégance.

L'objectif principal est de créer une vue dans laquelle les paramètres peuvent être utilisés directement, facilitant le regroupement et le filtrage des données. Considérez les vues MergedDenialsViewHelper et MergedDenials. Pour afficher les refus pour des utilisateurs et des fonctionnalités spécifiques dans un laps de temps défini, un paramètre est utilisé :

SET @DenialMergingTime := 5;
SELECT GroupTime, FeatureId, UserHostId, MultiplicitySum FROM MergedDenials WHERE UserHostId IN (1, 2) AND FeatureId IN (3, 4);

Cette méthode, bien qu'efficace, est problématique en raison de sa nature alambiquée. Une approche alternative existe : créer une fonction pour renvoyer la valeur du paramètre souhaité.

create function p1() returns INTEGER DETERMINISTIC NO SQL return @p1;

Par la suite, une vue peut être créée avec la fonction incorporée :

create view h_parm as
select * from sw_hardware_big where unit_id = p1() ;

Avec cette vue en place , les paramètres peuvent être directement utilisés :

select s.* from (select @p1:=12 p) parm , h_parm s;

Cette solution élimine le besoin de la solution de contournement précédente, simplifiant le processus global et améliorant la lisibilité du code.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!