Noget som dette burde gøre tricket (læs dog efter uddraget for mere info)
CREATE PROCEDURE GetFilteredData()
BEGIN
DECLARE bDone INT;
DECLARE var1 CHAR(16); -- or approriate type
DECLARE Var2 INT;
DECLARE Var3 VARCHAR(50);
DECLARE curs CURSOR FOR SELECT something FROM somewhere WHERE some stuff;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET bDone = 1;
DROP TEMPORARY TABLE IF EXISTS tblResults;
CREATE TEMPORARY TABLE IF NOT EXISTS tblResults (
--Fld1 type,
--Fld2 type,
--...
);
OPEN curs;
SET bDone = 0;
REPEAT
FETCH curs INTO var1,, b;
IF whatever_filtering_desired
-- here for whatever_transformation_may_be_desired
INSERT INTO tblResults VALUES (var1, var2, var3 ...);
END IF;
UNTIL bDone END REPEAT;
CLOSE curs;
SELECT * FROM tblResults;
END
Et par ting at overveje...
Angående uddraget ovenfor:
- måske ønsker at videregive en del af forespørgslen til den lagrede procedure, måske især søgekriterierne, for at gøre den mere generisk.
- Hvis denne metode skal kaldes af flere sessioner osv. kan det være en god ide at sende et sessions-id af slagsen for at skabe et unikt midlertidigt tabelnavn (faktisk unødvendig bekymring, da forskellige sessioner ikke deler det samme midlertidige filnavneområde; se kommentar af Gruber, nedenfor)
- Nogle få dele såsom variabeldeklarationerne, SELECT-forespørgslen osv. skal specificeres korrekt
Mere generelt:forsøger at undgå at have brug for en markør .
Jeg navngav med vilje markørvariablen curs[e], fordi cursorer er en blandet velsignelse. De kan hjælpe os med at implementere komplicerede forretningsregler, som kan være svære at udtrykke i den deklarative form af SQL, men det bringer os så til at bruge den proceduremæssige (imperative) form for SQL, som er en generel egenskab ved SQL, som hverken er særlig venlig/ udtryksfuldt, programmeringsmæssigt og ofte mindre effektivt præstationsmæssigt.
Måske kan du overveje at udtrykke den ønskede transformation og filtrering i sammenhæng med en "almindelig" (deklarativ) SQL-forespørgsel.