ugrás a tartalomhoz

left join feltétel

simisoma · Feb. 15. (P), 15.06
Sziasztok!

az lenne a kérdésem, hogy a lenti tábláim vannak mysql-ben:


1. nev:
id/veznev/kernev

2. eletkor:
id/eletkor

és lekérném a neveket úgy hogy left join -al hozzákapcsolom az életkort:
select nev.*,eletkor.eletkor from nev left join eletkor on(eletkor.id=nev.id)
ez szépen megy akkor is, ha nincs esetleg az életkor tábla feltöltve --> null értéket ad, ahogy beteszek egy feltételt az életkorra:
select nev.*,eletkor.eletkor from nev left join eletkor on(eletkor.id=nev.id) where eletkor.eletkor =!5
sajnos eltűnnek azok a sorok, ahol esetlegesen nincsen a névhez kapcsolódó életkor.

Hogy lehetne ezt a lehérést feltétellel úgy megoldani, hogy az összes nevet az életkorral listázza, ha nincsen hozzá életkor akkor null értéket adjon, de az 5 éveseket ne tegye a listába.

Húú, remélem érthetően írtam le, köszönöm előre is!
 
1

OR ... IS NULL

Endyl · Feb. 15. (P), 16.52
A NULL érték ismeretlen értéknek számít, így egy specifikus értékkel való összehasonlítása is ismeretlen; ezért nem kerülnek bele az eredményhalmazba az adott sorok.

Ha egy lekérdezésben egy mező értékére szűrsz, de a NULL-t tartalmazó sorokra is kíváncsi vagy, akkor hozzá kell adnod azt a feltételt is, hogy OR mezőneve IS NULL.
2

Köszönet

simisoma · Feb. 15. (P), 18.46
Hálás köszönetem a segítségedért, így már jó is :-)
3

Biztos, hogy ide két külön

inf3rno · Feb. 16. (Szo), 06.46
Biztos, hogy ide két külön tábla kell? Ha mindenkinek csak egy neve és életkora van, akkor simán mehetne egy táblába...
4

Ha már konkrétan MySQL, akkor

kuka · Feb. 16. (Szo), 15.04
Ha már konkrétan MySQL, akkor megemlíthető, hogy ott van egy külön <=> operátor:

select nev.*, eletkor.eletkor from nev left join eletkor on eletkor.id = nev.id where not eletkor.eletkor <=> 5
5

Még egy gondolat a témában,

inf3rno · Feb. 16. (Szo), 21.51
Még egy gondolat a témában, hogy nincs valami hatalmas jelentősége annak, ha két kérésben megy el. Ha rontja az olvashatóságot, akkor talán felesleges hosszú és bonyolult SQL queryket csinálni, mert premature optimization-nek számít. Ha tényleg optimalizálni kell, akkor is jobb lehet stored procedure-t és view-okat használni rá, mint hogy mindent megpróbáljunk belezsúfolni egy sorba.

off:
Nagyjából a kódolásnál is ugyanígy gondolom, azért lesz hányingerem sokszor az 1 soros method chaining-től, ami legtöbbször együtt jár a funkcionális programozással. Attól, hogy tömörebb, még nem lesz olvashatóbb az egész, mert azon kell agyalni, hogy mi történik a háttérben. Ha egy kicsit is bonyolultabb, akkor szét kell szedni több sorra, akkor meg már tökmindegy, hogy teszünk e be extra változókat a visszaadott értékek magyarázására. Egyedül talán stream pipe-olásnál látom értelmét CLI-ben az ilyen 1 soros dolgoknak, ha nem túl bonyolult, amiről szó van.
6

Lánc

Hidvégi Gábor · Feb. 21. (Cs), 10.49
Az off részben írtakkal messzemenőkig egyetértek. Nem elég, hogy jóval nehezebb értelmezni, a hibakezelés szempontjából sem túl előnyös megoldás a láncolás, mert azt feltételezi, hogy minden szem probléma nélkül lefut.