MySQL -> Boucle dans une table, exécutant une procédure stockée sur chaque entrée


9

J'ai une base de données avec des «livres» (histoires courtes pour les enfants) et il serait extrêmement instructif d'avoir le nombre de mots de chaque mot dans les livres.

J'ai compris comment obtenir le nombre de mots pour chaque mot en utilisant:

SELECT SUM
( 
    ROUND
    ( 
        (LENGTH(pageText) - LENGTH (REPLACE (pageText, "Word", "")))
        /LENGTH("Word")
    )
) FROM pages WHERE bookID = id;

Ce qui fonctionne à merveille pour compter les mots. MAIS cela me demande de parcourir chaque livre, de sortir chaque mot et de l'exécuter via cette fonction (je l'ai enregistré en tant que procédure stockée.)

J'ai un tableau qui contient chaque mot, sans doublons.

Ma question: existe-t-il un moyen de faire une sorte de boucle "pour chaque" sur la table Words en utilisant ma procédure stockée?

c'est à dire. passer la procédure stockée un ID de livre et un mot et enregistrer le résultat. Faire CHAQUE mot, pour CHAQUE livre. Cela me fait gagner BEAUCOUP de temps manuel ... Est-ce quelque chose que je devrais même faire du côté DB? Dois-je essayer avec PHP à la place?

Honnêtement, toute contribution est grandement appréciée!


1
Vous pouvez créer un tableau de (tous) les mots en analysant les livres. Ensuite, il deviendrait un choix pour relier les livres aux mots. Pas de boucles nécessaires là-bas.
jkavalik

Certaines tâches sont mieux effectuées dans un vrai langage de programmation, pas SQL. En PHP, cela pourrait ressembler à quelque chose count(explode(' ', $pageText))+1. Ou quelque chose de plus complexe pour gérer plusieurs espaces entre les mots, impliquant peut-êtrepreg_replace('/\s+/', ' ', $pageText)
Rick James

Pour Perl, cela peut être aussi court que 1+split(/\s+/, $pageText). Le 1 est dû au fait que le nombre est composé d'espaces et non de mots.
Rick James

Réponses:


14

Créez une deuxième procédure qui utilise deux curseurs imbriqués.

Les curseurs des procédures stockées vous permettent de faire quelque chose de très peu semblable à SQL: parcourir un jeu de résultats une ligne à la fois, placer les valeurs de colonne sélectionnées dans des variables et faire des choses avec.

Ils sont facilement utilisés à mauvais escient, car SQL, étant déclaratif plutôt que procédural, ne devrait généralement pas avoir besoin d'opérations de type "pour chaque", mais dans ce cas, cela semble être une application valide.

Une fois que vous les maîtrisez, les curseurs sont faciles, mais ils nécessitent une approche structurée dans leur code de prise en charge qui n'est pas toujours intuitive.

J'ai récemment fourni un code "standard" assez standard pour travailler avec un curseur pour appeler une procédure stockée dans une réponse sur Stack Overflow , et j'emprunterai très fortement à partir de cette réponse, ci-dessous.


L'utilisation d'un curseur nécessite un code standard standard pour l'entourer.

Vous SELECTles valeurs que vous souhaitez passer, d'où que vous les obteniez (qui pourrait être une table temporaire, une table de base ou une vue, et peut inclure des appels à des fonctions stockées), puis appelez votre procédure existinf avec ces valeurs.

Voici un exemple syntaxiquement valide du code nécessaire, avec des commentaires pour expliquer ce que fait chaque composant.

Cet exemple utilise 2 colonnes pour passer 2 valeurs à la procédure appelée.

Notez que les événements qui se produisent ici sont dans un ordre spécifique pour une raison. Les variables doivent être déclarées en premier, les curseurs doivent être déclarés avant leurs gestionnaires continus et les boucles doivent suivre toutes ces choses.

Vous ne pouvez pas faire les choses dans le désordre, donc lorsque vous imbriquez un curseur à l'intérieur d'un autre, vous devez réinitialiser la portée de la procédure en imbriquant du code supplémentaire à l'intérieur BEGIN... des ENDblocs dans le corps de la procédure; par exemple, si vous aviez besoin d'un deuxième curseur à l'intérieur de la boucle, vous le déclareriez simplement à l'intérieur de la boucle, à l'intérieur d'un autre BEGIN... ENDbloc.

DELIMITER $$

DROP PROCEDURE IF EXISTS `my_proc` $$
CREATE PROCEDURE `my_proc`(arg1 INT) -- 1 input argument; you might need more or fewer
BEGIN

-- declare the program variables where we'll hold the values we're sending into the procedure;
-- declare as many of them as there are input arguments to the second procedure,
-- with appropriate data types.

DECLARE val1 INT DEFAULT NULL;
DECLARE val2 INT DEFAULT NULL;

-- we need a boolean variable to tell us when the cursor is out of data

DECLARE done TINYINT DEFAULT FALSE;

-- declare a cursor to select the desired columns from the desired source table1
-- the input argument (which you might or might not need) is used in this example for row selection

DECLARE cursor1 -- cursor1 is an arbitrary label, an identifier for the cursor
 CURSOR FOR
 SELECT t1.c1, 
        t1.c2
   FROM table1 t1
  WHERE c3 = arg1; 

-- this fancy spacing is of course not required; all of this could go on the same line.

-- a cursor that runs out of data throws an exception; we need to catch this.
-- when the NOT FOUND condition fires, "done" -- which defaults to FALSE -- will be set to true,
-- and since this is a CONTINUE handler, execution continues with the next statement.   

DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

-- open the cursor

OPEN cursor1;

my_loop: -- loops have to have an arbitrary label; it's used to leave the loop
LOOP

  -- read the values from the next row that is available in the cursor

  FETCH NEXT FROM cursor1 INTO val1, val2;

  IF done THEN -- this will be true when we are out of rows to read, so we go to the statement after END LOOP.
    LEAVE my_loop; 
  ELSE -- val1 and val2 will be the next values from c1 and c2 in table t1, 
       -- so now we call the procedure with them for this "row"
    CALL the_other_procedure(val1,val2);
    -- maybe do more stuff here
  END IF;
END LOOP;

-- execution continues here when LEAVE my_loop is encountered;
-- you might have more things you want to do here

-- the cursor is implicitly closed when it goes out of scope, or can be explicitly closed if desired

CLOSE cursor1;

END $$

DELIMITER ;

Réponse fantastique, extrêmement informative! Je n'ai pas encore tout compris, mais avec les ressources fournies, je suis sûr que je peux faire fonctionner les curseurs! Je vous remercie!
Michael MacDonald

c'était super! l'utilisation de repeat / while a provoqué deux déclenchements de mon proc pour le dernier enregistrement, ce qui a nécessité des vérifications supplémentaires, mais cela résout ce problème.
Nick M

close cursor1; manque OPEN - CLOSE vont ensemble pour les curseurs
Miss Felicia A Kovacs

2
Les curseurs @MissFeliciaAKovacs ne peuvent exister que dans la portée d'un bloc BEGIN/ ENDet sont implicitement fermés lorsqu'ils sortent de la portée ... la fermeture des curseurs n'est donc pas strictement nécessaire. En pratique, je le considère inutile et ne l'inclut pas, mais pour être complet, j'ai ajouté la CLOSEdéclaration à la réponse.
Michael - sqlbot
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.