2025. május 07., szerda

Informatika

Adott napon: 
Keresés:
#3546
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ó) vidám vidám

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.



#3539
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.
#3509
A postot is látja fiddlerel pl, nincs értelme kitiltani a get-et, postot is tud küldeni bármikor ha hackelni akar. Sokkal inkább a mysql_real_escape_string és preg_match kombinációt érdemes alkalmazni, ez biztosabb és mindkettõ kizárja pl az sql injection-t.
#3507
- Többszörösen összetett SQL lekérdezés. Ez a néhány sor 2-3 nehéz órámba került. nevet Aki hasonló probléma megoldásán fáradozik, annak sokat segít.
- Program mûködése: csak abban az esetben tudja az illetõ felvenni a $_POST tárgyat, ha ötösre teljesítette azt (ETR-es rendszerekhez hasonló, csak ott ez 2-es). Tegnap kipróbáltam különbözõ kezdeti feltételekkel (közben kiderültek a hibák és azok javítva lettek) és végül hiba nélkül futott. Ha a tárgyhoz nem tartozik elõfeltétel, az illetõ gond nélkül felveszi és így lefut az update parancs is, hiszen a többszörösen összetett select utasítás IF vezérlési szerkezete automatikusan 1-et ad eredményül.
- Az sql parancs nyilván nem kerül a kukába, hanem alap,közép,emeltszintû fórumjog megszerzéséhez irányuló vizsgatárgyak felvételét teszi majd lehetõvé. Aki ötösre teljesíti az alapszintet, az fórumjogot szerez, ezzel megvan az elõfeltétel és föl tudja venni a közép, majd az emeltszintû tárgyakat (ezeket nem kötelezõ felvenni, bár a stréberebbeknek ajánlott, hiszen a fórumjog nem vész el, ha azok már nem sikerülnek nevet ).

PHP-MYSQL programkód:

< ?php
$sql = "UPDATE kurzustabla SET KRT_JELENTK=CONCAT(KRT_JELENTK,'"._US_ID_."|') WHERE KRT_ID='".$_POST."' AND (SELECT IF((SELECT 'OK' FROM exam WHERE (SELECT TRG_ELOFELT FROM targylist WHERE TRG_KOD='".$_POST."' limit 1) LIKE CONCAT('%',EX_TRG_KOD,'%') AND EX_TELJESIT LIKE '%."._US_ID_."||5%' limit 1)='OK' OR (SELECT TRG_ELOFELT FROM targylist WHERE TRG_KOD='".$_POST."' limit 1)='',1,0)) = 1";

if(!mysql_query($sql)) {print mysql_error(); }
elseif(mysql_affected_rows()!=1) { print $_POST." kurzus felvétele sikertelen hiányzó elõfeltétel miatt!";}
else { print $_POST." kurzus felvétele sikeres!";}
? >

Utolsó észlelés

2025-05-07 19:10:10

Kõszeg

13.1 °C

RH: 63 | P: 1014.6

Észlelési napló

Térképek

Radar
map
Aktuális hõmérséklet
map
Aktuális szél
map

Utolsó kép

139227

Hírek, események

Indul a MetNet előrejelzési verseny sorozatának 42. sorozata

MetNet | 2025-05-01 14:48

pic
Kis pihenés után folytatódhat a meteorológiai megmérettetés, immáron 42.