Coś takiego powinno wystarczyć (jednak przeczytaj po fragmencie, aby uzyskać więcej informacji)
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
Kilka rzeczy do rozważenia...
Odnośnie powyższego fragmentu:
- może chcieć przekazać część zapytania do procedury składowanej, w szczególności kryteriów wyszukiwania, aby uczynić je bardziej ogólnymi.
- Jeśli ta metoda ma być wywoływana przez wiele sesji itp., możesz chcieć przekazać rodzaj identyfikatora sesji, aby utworzyć unikalną nazwę tabeli tymczasowej (właściwie to niepotrzebna obawa, ponieważ różne sesje nie współdzielą tej samej przestrzeni nazw plików tymczasowych; zobacz komentarz przez Gruber, poniżej)
- Kilka części, takich jak deklaracje zmiennych, zapytanie SELECT itp. należy odpowiednio określić
Bardziej ogólnie:próba uniknięcia konieczności używania kursora .
Celowo nazwałem zmienną kursora curs[e], ponieważ kursory są mieszanym błogosławieństwem. Mogą nam pomóc zaimplementować skomplikowane reguły biznesowe, które mogą być trudne do wyrażenia w deklaratywnej formie SQL, ale następnie prowadzą nas do użycia proceduralnej (imperatywnej) formy SQL, która jest ogólną cechą SQL, która nie jest zbyt przyjazna/ ekspresyjny, programistyczny i często mniej wydajny pod względem wydajności.
Może przyjrzysz się wyrażaniu pożądanej transformacji i filtrowaniu w kontekście „zwykłego” (deklaratywnego) zapytania SQL.