Köszi a javaslatokat, kipróbálom õket. Az sql -t 1,5-2 éve tanulom, nyilván egy fél éves kurzus során egyszerû lekérdezésekre futott csak. A tudásomat folyamatosan bõvítem, a Right és a Left Join parancsokat mind a mai…
Köszi a javaslatokat, kipróbálom õket.
Az sql -t 1,5-2 éve tanulom, nyilván egy fél éves kurzus során egyszerû lekérdezésekre futott csak. A tudásomat folyamatosan bõvítem, a Right és a Left Join parancsokat mind a mai napig nem értem, éppen ezért nem használom õket, bár hasonlóképp vagyok a not exist parancsokkal is. A lekérdezések unióját sem régen ismerem (union). A limitet csak akkor használom, ha csak egy rekordot szeretnék listázni, ez pedig az IF parancs miatt szükséges, mert ha pl. 2 rekordot kapna az elsõ argumentumban akkor baj lenne.
Sajnos az érdemjegyeket helymegtakarítás miatt a felhasználó azonosítójával párosítom, (emiatt a like elkerülhetetlen) pl. így szerepel az adatbázisban: .202|4.12|5.63|2. stb...
A táblákat mindig indexelem, az elsõ oszlop mindig az elsõdleges kulcsom, ahol egy automatikusan növekvõ számsorozat jön létre (auto increment hatására), pl. ha 2x vinném be ugyanazt a számot duplicate entry hibaüzenetet kapnék a mysql_error() - tól.
Az egymásba ágyazott lekérdezések (bár a tábla összekapcsolások is) sokszor kényelmetlenek, de nagyon hasznosak, mivel nem kell millió egy lekérdezést egymás után elküldeni, továbbá nem kell a kapott PHP-s asszociatív tömböt meg a következõ lekérdezésbe betenni. A Select utáni "*" valóban lassítja a futásidõt, hiszen ha nem kell minden mezõ adata nekem, akkor nem is kérem, én ilyenkor sosem szoktam kitenni a csillagot, csak azt, amivel dolgozni szeretnék. A futásidõvel nem szokott baj lenni, néhány ezred másodperc alatt lefut. A having parancsokat és a min, max fv-eket gyakran használom a GROUP BY-al együtt, legfõképpen statisztikák készítésénél.
A sprintf és társai a C nyelvbõl ismerõsek, noha ebben a nyelvben nagyon amatõr vagyok még.
select A.*, B.* from A left join B on oszlop: az A tábla
minden sora benne lesz az eredményben, a B táblából csak azok, amelyeket megtalál, mindenhol másutt a B.* oszlopokban NULL jön vissza. Right join ugyanez, csak a B tábla minden sora lesz benne az eredményben.
A not exist csak egy logikai feltétel és akkor lesz igaz, ha a mögötte lévõ select nem ad vissza egyetlen rekordot sem.
A union egy result setbe gyûjti az elõtte és az utána lévõ lekérdezés eredményeit, feltétel, hogy azonos oszlopok legyenek mindkét helyen, pl : select a.a union b.a . Ez distinct eredményt ad vissza, a mindkét selectben meglévõ sorokat csak egyszer fogja hozni. Ha azt írod, hogy union all, akkor az minden sort visszaad, a mindkét selectben meglévõ sort kétszer fogja visszaadni.
"Sajnos az érdemjegyeket helymegtakarítás miatt a felhasználó azonosítójával párosítom, (emiatt a like elkerülhetetlen) pl. így szerepel az adatbázisban: .202|4.12|5.63|2. stb... " : nem érdemes a hellyel ennyire spórolni, ez 2-8 byte soronként (tinyint(2)) , ez nagyjából semmi és sokkal több feljesztés kell hozzá, nem éri meg ilyen szinten. Arról nem is beszélve hogy ha ezt az oszlopot is indexeled, az úgyis elviszi a spórolt helyet.
Ehelyett egy másik kis táblába lehet gyûjteni a jegyeket, oszlopai lehetnek pl userid, tantargyid, jegy, ez 2 int és egy smallint oszlop, összesen 9 byte/sor, ennél jobban nem érdemes spórolni.
A select * azért nem jó, mert akkor mindig megnézi a tábla sémáját, hogy tudja, milyen oszlopok vannak a táblában, ez idõveszteség + feleslegesen rágja a diszket.
Az egymásba ágyazott lekérdezéssel az lehet a baj, hogy lehet olyat írni, amikor a belsõ select az eredmény
minden sorára lefut egyszer, ami nem kifejezetten performanciális (szép magyar szó)
Az auto increment nem biztonságos, a post átírásával könnyû más rekordokat hackelni, a GUID (php-ban uuid()) jobb ilyesmire.
A sprintf nem csinál mást, csak összepakol egy stringet helyetted, nem kell az idézõjelek százait leirnod.
