Hirdetés
- talmida: Változások 2. rész
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: MárkaLánc
- sziku69: Szólánc.
- DeFranco: Tanuljunk angolul játékosan! - Duolingo
- sziku69: Fűzzük össze a szavakat :)
- gerner1
- Luck Dragon: Asszociációs játék. :)
- hmzs: Fujitsu Futro S920 csúcsra járatva
- Magga: PLEX: multimédia az egész lakásban
Új hozzászólás Aktív témák
-
bpx
őstag
A kérdés az volt, hogy azok a sorok kellenek amelyek ID-ja csak egyszer szerepel a táblában, továbbá igaz rájuk, hogy status = open, type = 477.
Nálad a status = open, type = 477 szűrés az aggregráció előtt történik, mert az a WHERE-ben van, nem a HAVING-ben.
Emiatt ha pl. így néz ki a tábla, akkor az eredményedbe mindkettő sor bekerül:
id | status | type
--------|--------|------
1 | open | 477
1 | closed | 476Erre nem teljesül az, hogy az ID csak egyszer szerepel, hiszen 2 sorban is ott van, és mivel csak az ID alapján történik a self join, visszadja az ID-hoz tartozó összes többi sort is, amelyekre a status = open, type = 477 nem teljesül.
A min(status) meg min(type) részhez annyi, hogy a having count(*) miatt eleve csak az 1 tagú csoportokat vizsgáljuk, ahova mindegy, hogy min vagy max vagy más csoport függvényt írok, de valamit muszáj, hogy megegye az aggregráció + having. A havingben ott van utána még a számunkra szükséges szűrés, ez az aggregáció után történik, és az 1 elemű csoportokból csak a nekünk szükségeseket hagyja meg.
Szerintem a kérdés direkt van ilyen egyszerűre fogalmazva, hogy meg lehessen oldani subquery meg analitikus függvény nélkül.
Új hozzászólás Aktív témák
- BESZÁMÍTÁS! GIGABYTE B360N i5 9600KF 16GB DDR4 512GB SSD GTX 1660 Super 6GB Zalman T3 Plus 400W
- Beszámítás! Sony PlayStation 5 825GB SSD lemezes konzol garanciával hibátlan működéssel
- iPhone 17 256GB - BONTATLAN - (3év)
- Xiaomi Redmi 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
