Bármi, ami MySQL -lel kapcsolatos
Az előző fejezetekben írtam arról, hogy néha egyszerre több verzióra lehet szükség webszerverből és/vagy php-ból, de ez ugyanúgy igaz lehet a mysql szerverre is. Más verziók, más hibák. És ezeket nem árt tesztelni, ha nem egy konkrét konfigurációra koncentrálva készül a program. De mikor és mit érdemes többszörözni?
Triggerek a MySQL 5.0 óta léteznek. Egy trigger bizonyos táblaműveletek hatására kiváltódó események kezelésére szolgál, amiben tárolt eljáráshoz hasonló szintaktikával további műveletek végezhetők. Bár még nem olyan kifinomult a MySQL trigger, mint például Oracle-ben, de be fogom mutatni, hogy így is hasznos szolgálatot tehet, amennyiben van jogosultságunk a használatára.
Triggerek létrehozása:
Egy utasítás esetén:
create trigger triggerneve mikorfusson milyenmuveletre for each row sqlutasitas;
Több utasítás esetén:
mikorfusson: Lehet before vagy after.
Azaz egy művelet előtt is lefuthat, vagy csak az után.
milyenmuveletre: Lehet insert, update vagy delete
A „create” előtti sorra azért van szükség, mert a trigger törzsében levő sql utasítások utáni pontosvessző lezárná a triggert is. Meg kell tehát változtatni a delimitert, azaz az utasításokat határoló karaktert. A trigger lezárása után pedig vissza lehet azt állítani. Most pedig jöjjön egy életszerű példa a triggerek használatára!
Tudjuk vagy sem, de MySQL-ben a mező választott karakterkészletétől függ, hogy kereséskor egy WHERE feltételben számít-e a kis- és nagybetűk különbsége. Elsőre lehet nem tűnik fontosnak ez a kérdés. De cseppet sem mindegy, hogy egy loginrendszernél például ugyanannak számít-e Bela és bela. Ugyanakkor egy jelszónál ( amit egyébként nem nagyon szokás hashelés nélkül tárolni ) pedig fontos, hogy különbözzön 123ABC és 123aBc. Most nem tudok jobb példát mondani. De akkor milyen karakterkészletet válasszunk? Erről fogok írni pár szót.
Bele is vágnék. Ki gondolta volna, hogy egyszer meg akarom számolni majd hány sort kérdeztem le adatbázisból, amikor használtam a limit záradékot, és én magam mondtam meg, hogy maximum hány sor lehet. Most mégis eljött ez a nap. Nézzük a következő lekérdezést:
select count(*) from tablaneve limit 40, 10
Logikusnak tűnne, hogy amennyiben van legalább 50 rekordom a tablaneve táblában, akkor visszaadja a 10-et a count(*) hatására, és ha nincs, akkor pedig annyit, amennyit le tudott kérdezni. De ez nincs így. Nem fog visszaadni egyetlen sort sem. Még csak nullát sem ad eredményül.
Mit lehet tehát tenni?
Létezik mysql-ben a found_rows() nevű furcsa függvény, amit meghívva megkapjuk az előző lekérdezésre illeszkedő sorok száma + a limitben megadott offset értéket. Tehát:
Megkapjuk, hogy 50, amennyiben volt legalább 50 sor. Ha csak 45 sor van az adatbázisban, akkor 45-öt eredményez. Az SQL_CALC_FOUND_ROWS opciót használva az első lekérdezésben azt lehet megmondani a mysql-nek, hogy az utána futtatandó found_rows() függvény hagyja figyelmen kívül a limit-et, és az összes sor számát adja vissza. Tehát:
Kimenete lehet akár 300 is, ha a tablaneve táblában 300 rekord van.
Ezek ismeretében tehát a sorok számát meghatározhatjuk, ha az SQL_CALC_FOUND_ROWS használata nélkül lekérdezzük a rekordokat, majd a found_rows() visszatérési értékéből kivonjuk az offset értéket:
Persze így lehet negatív szám is az eredmény. De ha ez probléma, akkor azon is segít egy if.
A másik megoldás két egymásba ágyazott select, ahol a belső select eredménye tölti be a külső select-ben a tábla szerepét, és akkor már használható a count(*) is:
select count(*) from (select * from tablaneve limit 40, 10) as t
Aliast kötelező adni a belső select -nek.
Persze ha nem SQL-ben lett volna szükség erre a számolásra, akkor például PHP-ből meghívtam volna a lekérdezésre a mysql_num_rows() függvényt, és kész vagyok. De a leírtak arra adnak megoldást, amikor már sql-ben szükség van az értékre.