MySQL : @variable vs. variable. Quelle est la différence ?

Question

Dans une autre question que j'ai postée, quelqu'un m'a dit qu'il y a une différence entre :

@variable

et :

variable

dans MySQL. Il a également mentionné comment MSSQL a une portée de lot et MySQL a une portée de session. Quelqu'un peut-il me donner des précisions à ce sujet ?

Answer 1

MySQL a un concept de variables définies par l'utilisateur .

Ce sont des variables faiblement typées qui peuvent être initialisées quelque part dans une session et conserver leur valeur jusqu'à la fin de la session.

Ils sont précédés d'un @ signe, comme ceci : @var

Vous pouvez initialiser cette variable avec un SET ou dans une requête :

SET @var = 1

SELECT @var2 := 2

Lorsque vous développez une procédure stockée dans MySQL, vous pouvez passer les paramètres d'entrée et déclarer les variables locales :

DELIMITER //

CREATE PROCEDURE prc_test (var INT)
BEGIN
    DECLARE  var2 INT;
    SET var2 = 1;
    SELECT  var2;
END;
//

DELIMITER ;

Ces variables ne sont pas précédées d'un préfixe.

La différence entre une variable de procédure et une variable définie par l'utilisateur spécifique à la session est qu'une variable de procédure est réinitialisée pour NULL à chaque fois que la procédure est appelée, alors que la variable spécifique à la session ne l'est pas :

CREATE PROCEDURE prc_test ()
BEGIN
    DECLARE var2 INT DEFAULT 1;
    SET var2 = var2 + 1;
    SET @var2 = @var2 + 1;
    SELECT  var2, @var2;
END;

SET @var2 = 1;

CALL prc_test();

var2  @var2
---   ---
2     2

CALL prc_test();

var2  @var2
---   ---
2     3

CALL prc_test();

var2  @var2
---   ---
2     4

Comme vous pouvez le voir, var2 (variable de procédure) est réinitialisée à chaque fois que la procédure est appelée, alors que @var2 (variable spécifique à la session) ne l'est pas.

(En plus des variables définies par l'utilisateur, MySQL également possède certaines "variables système" prédéfinies, qui peuvent être des "variables globales" telles que @@global.port ou des "variables de session" telles que @@session.sql_mode ; ces "variables de session" n'ont aucun rapport avec les variables définies par l'utilisateur spécifiques à la session).

Answer 2

Dans MySQL, @variable indique un variable définie par l'utilisateur . Vous pouvez définir les vôtres.

SET @a = 'test';
SELECT @a;

En dehors des programmes enregistrés, une variable sans @ est un variable du système que vous ne pouvez pas définir vous-même.

La portée de cette variable est l'ensemble de la session. Cela signifie que tant que votre connexion avec la base de données existe, la variable peut toujours être utilisée.

Ceci est en contraste avec MSSQL, où la variable ne sera disponible que dans le lot actuel de requêtes (procédure stockée, script, ou autre). Elle ne sera pas disponible dans un lot différent dans la même session.

Answer 3

MSSQL exige que les variables à l'intérieur des procédures soient DECLAREd et que les personnes utilisent l'attribut @Variable syntaxe ( DECLARE @TEXT VARCHAR(25) = 'text' ). De plus, MS permet les déclarations dans n'importe quel bloc de la procédure, contrairement à MySQL qui exige toutes les DECLARE en haut.

Bien qu'il soit bon en ligne de commande, je pense que l'utilisation de l'option set = @variable dans les procédures stockées de MySQL est risqué. Il n'y a pas de portée et les variables vivent au-delà des limites de la portée. Ceci est similaire aux variables en JavaScript qui sont déclarées sans l'attribut var qui sont alors l'espace de nom global et créent des collisions et des écrasements inattendus.

J'espère que les bonnes gens de MySQL vont autoriser DECLARE @Variable à différents niveaux de bloc dans une procédure stockée. Remarquez les @ (au panneau). Le site @ Le préfixe du signe permet de séparer les noms de variables des noms de colonnes de tables, car ils sont souvent identiques. Bien sûr, il est toujours possible d'ajouter un préfixe "v" ou "l_", mais l'option @ est un moyen pratique et succinct de faire correspondre le nom de la variable à la colonne dont vous pourriez extraire les données, sans pour autant l'alourdir.

MySQL est un nouveau venu dans le domaine des procédures stockées et ils ont fait du bon travail pour leur première version. Ce sera un plaisir de voir où ils vont aller à partir de là et de voir les aspects côté serveur du langage mûrir.

Answer 4

En principe, j'utilise les UserDefinedVariables (précédées de @) dans les procédures stockées. Cela me facilite la vie, surtout lorsque j'ai besoin de ces variables dans deux ou plusieurs procédures stockées. Lorsque je n'ai besoin d'une variable que dans une seule procédure stockée, j'utilise une variable système (sans le préfixe @).

@Xybo : Je ne comprends pas pourquoi utiliser des @variables dans des StoredProcedures devrait être risqué. Pourriez-vous expliquer "scope" et "boundaries" un peu plus facilement (pour moi qui suis novice) ?

Answer 5

@variable est très utile si l'on appelle procédures stockées à partir d'une application écrite en Java, Python, etc. Il arrive que les valeurs des variables soient créées lors du premier appel et qu'elles soient nécessaires aux fonctions des appels suivants.

Note complémentaire sur PL/SQL (Oracle)

L'avantage est visible dans Oracle PL/SQL où ces variables ont 3 portées différentes :

• Variable de fonction dont la portée se termine à la sortie de la fonction.
• Variables du corps du paquet défini au sommet du paquet et en dehors de toutes les fonctions dont la portée est la session et la visibilité est le paquet.
• Variable du paquet dont la variable est la session et la visibilité est globale.

Mon expérience en PL/SQL

J'ai développé une architecture dans laquelle le code complet est écrit en PL/SQL. Ceux-ci sont appelés à partir d'un middle-ware écrit en Java. Il y a deux types de middle-ware. L'un pour répondre aux appels d'un client qui est également écrit en Java. L'autre pour répondre aux appels provenant d'un navigateur. Le dispositif client est implémenté à 100 % en JavaScript. Un jeu de commandes est utilisé au lieu de HTML et JavaScript pour écrire une application en PL/SQL.

J'ai cherché la même facilité pour porter les codes écrits en PL/SQL vers une autre base de données. La solution la plus proche que j'ai trouvée est Postgres . Mais toutes les variables ont une portée de fonction.

Opinion à l'égard de @ dans MySQL

Je suis heureux de voir qu'au moins cette @ est disponible dans MySQL. Je ne pense pas qu'Oracle construira la même facilité disponible dans PL/SQL pour les procédures stockées de MySQL car cela pourrait affecter les ventes de la base de données Oracle.