- Computex 2024: monstrumhűtő a DeepCoolnál (videóval!)
- Computex 2024: szimpatikus Montech billentyűzetek a porondon
- Computex 2024: háznézőben a Montech asztalainál
- Computex 2024: kompakt AIO-k és tápegységek a Montech receptje alapján
- Computex 2024: a Ducky klaviatúrái sem restek felülni az analóg vonatra
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- ThinkPad (NEM IdeaPad)
- Azonnali fotós kérdések órája
- Apple notebookok
- Computex 2024: feltárta a Lunar Lake-et az Intel
- Azonnali alaplapos kérdések órája
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Bluetooth hangszórók
- Milyen monitort vegyek?
- Mini-ITX
Hirdetés
-
Computex 2024: háznézőben a Montech asztalainál
ph A vállalat sok portékájának közös vonása, hogy a csatlakozóikat túlsó felükre száműző alaplapokat és az óriásira hízott VGA-kat is tárt karokkal várják.
-
SGF24 - Befutott a Monster Hunter Wilds legújabb előzetese
gp Az új rész jövőre érkezik, ennél pontosabb dátumot nem kaptunk még sajnos.
-
Új Reno12 modellek is érkeznek
ma A Reno12 Pro mellett belépő ajánlatokkal is készül az Oppo, a Reno12 F 4G-s és 5G-s verzióban is elérhető lesz.
Új hozzászólás Aktív témák
-
nyunyu
félisten
Talán még ez a legegyszerűbb, de előző főnököm hivatalból rühellte a distinctet, úgyhogy olyat nagyon ritkán használunk.
Szerinte az adathibát javítani kell, nem eltakarni!
(Mostani melóhelyem viszont DWHt örökölt, úgyhogy javíthatatlan adathiba adathiba hátán a default felállás.)
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Ha nagyon elegánsak akarnánk lenni, akkor:
select t.a, t.b
from tabla t
where t.a in (select t1.a
from tabla t1
join tabla t2
on t2.a = t1.a
and t2.b <> t1.b);[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
pvt.peter
őstag
Sziasztok,
Jól gondolom, hogy nincs az alábbiakra lehetőségem MS SQL -ben?
Van egy A, B, C nevű tábla 1-1 int típusú oszloppal.
Amit szeretnék, hogy C tábla int típusú oszlopában csak olyan értéket lehessen felvenni ami szerepel az A vagy a B oszlop int típusú oszlopában.
A foreign key megoldás erre, de ha jól gondolom ez egy ÉS típusú kapcsolat.
Tehát ha kettő foreign keyt adok a C táblához ami az A és B tábla megfelelő oszlopára utal, akkor csak olyan értéket tudok ezek után felvenni a C tábla megfelelő oszlopában ami mind a kettő korábban említett táblában szerepel.
Van lehetőségem arra, hogy ezt az ÉS kapcsolatot VAGY -ra cseréljem?
Tehát csak olyan érték kerülhessen a C tábla adott oszlopába ami szerepel az A vagy a B oszlop megfelelő oszlopában?Köszi a választ.
Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
tm5
tag
válasz pvt.peter #4762 üzenetére
Itt tárgyalnak 1-2 opciót, mindegyiknek az a lényege, hogy 2 külön oszlop legyen a 2 referencia. Az egyik azt mondja, hogy tedd őket egy külön táblába, a másik rögtön a céltáblába (nálad ez a C tábla) és egy CONSTRAINT CHECK-kel lehet ellenőrizni.
Nekem alternatívaként még 2 dolog jutott eszembe:
- ellenőrzés Insert triggerben, itt van is egy példa rá
- írsz egy tárolt eljárást az INSERT-re és ott már azt ellenőrzöl ami jól esik. -
pvt.peter
őstag
Köszi a válaszokat, neked is #4764 Ispy.
A legegyszerűbb megoldás tényleg az lenne, hogy ha külön-külön oszlop lenne létrehozva a C táblában az A és B tábla oszlopaira.
De a trigger is járható út, bár nemtom, hogy performanciában ez okoz-e vmilyen hátrányt.
Mindenesetre köszönöm még egyszer a válaszokat.Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
Micsurin
nagyúr
Hello! Nagyon ovi és dedo kérdés de egyszerűen nem akaródzik működni (Centos OS + Oracle 12c virtuális gépen, gyakran produkál érdekeseket), de
SELECT allapot AS "Állapot", ROUND(AVG(ar),2) AS "Átlag ár"
FROM motorok GROUP BY allapot HAVING ar < 5000000;
Nem az az ökölszabály, hogy a csoportostás alanyát kell SELECT után és azon kívül COUNT, Min, Max etc mehet? Akkor mégis miért kapok:
Köszi előre is!
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
válasz martonx #4767 üzenetére
De várj már a having az azért lenne, hogy az Új és a Használt gépek esetében is csak azokat vegye figyelembe a csoportosítás után az átlaghoz amik ára 5m alatti.
Ha ott átlagolok az kicsit felrúgna mindent.
Vagy én értem nagyon félre? Adatb-hez mindig is szobanövény voltam mert nem is érdekelt különösebben.Igen így kevésbé hányok a féléves beadandómtól.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
válasz Micsurin #4766 üzenetére
HAVING nélkül lefut de bele kéne szuszakoljam a lekérdezésbe. Már pedig a motorok ár alapú korlátja lenne a legegyszerűbb.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
nyunyu
félisten
válasz Micsurin #4766 üzenetére
Most mit szeretnél?
Átlagár legyen 5 misi alatt?
Ehhez kell az oszlopfüggvények kiértékelése utáni eredményhalmazt szűrő HAVING, de ahhoz pontosan ugyanazt a képletet kell írni, mint ami a mezőlistánál van:SELECT allapot AS "Állapot", ROUND(AVG(ar),2) AS "Átlag ár"
FROM motorok
GROUP BY allapot
HAVING ROUND(AVG(ar),2) < 5000000;5 misi alattiakat átlagolni?
-> először 5M-re kéne szűrni WHERErel, és azt átlagolni:SELECT allapot AS "Állapot", ROUND(AVG(ar),2) AS "Átlag ár"
FROM motorok
WHERE ar < 5000000
GROUP BY allapot;WHERE mindig a rekordokat szűri, és a szűrt rekordokon futnak le a csoportosítások/számítások.
HAVING a már kész, kikalkulált eredményhalmazt szűri.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Micsurin
nagyúr
HAVING nem volt meg pontosan mire is köszönöm!
Én sem tudom mit szeretnék kellett adatbázist tervezni, majd megszorítások majd lekérdezések. Most megy kb a gyurmázás legozás, hogy utólag menjenek a megszabások szerinti lekérdezések.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
nyunyu
félisten
Mivel a queryk egymásba ágyazhatóak, így a HAVINGet akár ki is lehet váltani WHERErel:
SELECT *
FROM (
SELECT allapot,, ROUND(AVG(ar),2) AS atlag_ar
FROM motorok
GROUP BY allapot
)
WHERE atlag_ar < 5000000;Nem is emlékszem, mikor használtam utoljára HAVING-et.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Micsurin
nagyúr
Wow jogos, köszönöm ezt felvésem jól jön ez még a beágyazottaknál.
Nem opcionális a használata meglett mondva 3db GROUP + HAVING lekérdezés akkor azt így kell... valamit beleszuszakolok még ebbe és jó lesz nem értelmes kell legyen mint megoldása egy problémának csak szintaktikailag jónak.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
veterán
Sziasztok,
van egy selectem, aminek az eredménye két sor. Meg tudom azt csinálni, hogy az eredmények egymás mellé és ne egymás alá érkezzenek?
Köszi -
Apollo17hu
őstag
Transzponálhatod pl. PIVOT függvénnyel, vagy lekorlátozhatod az eredeti selectet úgy, hogy csak az egyik eredménysort adja vissza, aztán egy másik selectben pedig csak a másik eredménysort. Ha utóbbit választod, akkor mehet rá a Descartes-szorzat:
SELECT egyik.mezo AS mezo_1, masik.mezo AS mezo_2
FROM (egyik_select) AS egyik, (masik_select) AS masik
-
veterán
válasz Apollo17hu #4775 üzenetére
Köszönöm
Jelenleg 4 select van így egybe, hogy az első a másaodik from-jában van, majd ez az egész a harmadikban, és végül ez az egész egy negyedikben. És itt a harmadik réteg selectembe van egy feltétel aminek csak egy kimenete lehet. Es itt jött képbe, hogy innen kellene még egy adat....
Ahha, asszem értem, hogy fog össze állni, köszi -
Micsurin
nagyúr
Mitől függ, hogy miképp hivatkozok egy subquerryre?
Kicsit kavarodás van fejben mert két esetet nem igazán ismerek fel a típus feladatokban:
Mikor mint tábla kezeljük a subquerryt és INNER vagy NATURAl JOIN-al fűzzük hozzá a lekérdezéshez és mikor elnevezzük a keresett értékeket pl dolgozok és a subquerry megy a FROM mögé mint dolgozok d, (subquerry) kereset majd WHERE segítségével helyezzük kontextusba az értékeket.
(próbáltam formázni de a PPT-ben is istentelenül tördelve és szóközölve volt... )Egyik: részlegenként listázva a minimális béreket
SELECT e.department_id, last_name, legkisebb
FROM employees e, (SELECT department_id, MIN(salary) legkisebb
FROM employees GROUP BY department_id) min
WHERE e.salary=min.legkisebb AND e.department_id=min.department_id;
A másik meg:
Listázzuk azon dolgozók vezetéknevét, fizetését és részlegük nevét, akik többet keresnek, mint amennyi a részlegük átlagfizetése.
SELECT last_name, salary, department_name
FROM employees INNER JOIN departments USING (department_id) NATURAL JOIN
(SELECT department_id, ROUND(AVG(salary)) részlegátlag FROM employees
GROUP BY department_id) WHERE salary > részlegátlag;
edit.: Ennél azt használom ki, hogy minden adatom megvan az eredeti táblában és a keresés által visszakapott "adat halmazban" is ezáltal mint táblát tudom kapcsolni és soronként kezeli az adatokat? Ilyen elven az első is mehetne így nem?
Nem tudom mennyire érthető a gondom.
De előre is nagyon köszi, hatalmas segítség lenne ha letisztulna melyik kapcsolatot honnan ismerem fel szöveg alapján![ Szerkesztve ]
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
válasz Micsurin #4777 üzenetére
Annyival tudom finomítani, hogy ha jól értem a dolgot azzal van gondom nem ismerem fel mikor kéne az allekérdezést:
-Mező
-Tábla
-Feltétel
Helyett használnom. Ill a mező helyetti az egyértelmű én a tábla és a feltételt nem ismerem fel, hogy feladat szövegben mire kéne figyeljek, hogy feltűnjön.Az kezd egyértelmű lenni, hogy az 1. példa lesz a feltétel és értelemszerűen 2. példa a tábla helyetti.
Tudom nagyon lámán értelmezem! De itt nem a megszokott demo srácok tartották a labort és a tanárt aki beugrott nem igazán értettem.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Szmeby
tag
válasz Micsurin #4778 üzenetére
Nem hiszem, hogy a feladat szovegeben talalni fogsz egy kulcsszot, ami elarulja, mit hova tegyel egy lekerdezesben.
En sem ertem pontosan a problemat, de ha az a gondod, hogy nem latod a kulonbseget a
SELECT e.department_id, last_name, legkisebb
FROM employees e, (SELECT department_id, MIN(salary) legkisebb
FROM employees GROUP BY department_id) min
WHERE e.salary=min.legkisebb AND e.department_id=min.department_id;es a
SELECT e.department_id, last_name, legkisebb
FROM employees e
INNER JOIN (SELECT department_id, MIN(salary) legkisebb
FROM employees GROUP BY department_id) min ON e.department_id=min.department_id
WHERE e.salary=min.legkisebb;kozott, akkor az azert van, mert nincs kulonbseg.
En az utobbi formatumot szoktam meg es szeretem hasznalni. Az utobbi egy ujabb talalmany, a hosidokben az elobbit hasznaltak. De ez a ketfele formatum a subquerytol pont fuggetlen, sima tablakkal ugyanugy alkalmazhato mindket forma.---
Hogy subqueryt tablakent hasznalsz egy lekerdezesben es joinolgatsz, vagy a where feltetelben szursz a subquery eredmenyevel egy masik tabla egy mezojen*, szerintem ez ket annyira eltero dolog, hogy adja magat. Join-ba azert teszed, mert mondjuk a subquery-bol is szeretnel ertekeket megmutatni az eredmenyhalmazban. Vagy mert tobb mezore is szurnel, es join-nal atlathatobb a lekerdezes, vagy mert a DB jobban optimalizalja igy a lekerdezest, mint ugy. Probalgasd, gyakorolj, idovel raerzel!
* Mondjuk valami ilyesmi:
SELECT e.department_id, last_name
FROM employees e
WHERE e.salary=(SELECT MIN(salary) FROM employees min WHERE e.department_id=min.department_id);---
Vagy ha a subqueryt a szelekcioba rakod, hat, meg nem mondom, mikor van ennek haszna. Annyira nem vagyok expert, hogy ezt most igy hirtelen meg tudjam fogalmazni, es sose filozofalgattam azon, hogy milyen kulcsszavak milyen strukturaltsagot implikalnanak. Szelekcioba nagyon ritkan tettem subselectet, mert borzaszto rossz hatasfoku volt.
Szerintem egy jo okolszabaly, hogy ird meg join-nal a lekerdezest, es ha azt latod, hogy a join felesleges, mert mondjuk a kapcsolt tablabol semmit nem mutatsz meg az eredmenyhalmazban, akkor kis atalakitassal talalj neki egy szebb / jobb formatumot. Erdemes kiprobalni, hogy mennyire hatekonyan hajtja vegre a DB az egyik es a masik valtozatot. Sok gyakorlas utan pedig mar raerzel majd, hogy melyik megoldas optimalis, es eleve ugy kezdesz hozza. Meg az exists egy olyan okossag, ami egesz jo hatekonysagot mutat, annak a probalgatasat is ajanlom.
Ha elkepzeled, hogy melyik tabla vagy subquery hany sorral ter vissza, es az alapjan probalod beloni, hogy a DB vajon egyik-masik konstrukcioban mennyire izzadna meg, akkor az talan segit eldonteni, hogy merre erdemes elindulni.
Na de en is kivancsi vagyok egy hozzaerto gondolataira, hatha van egyszerubb mod.
[ Szerkesztve ]
-
nyunyu
félisten
válasz Micsurin #4777 üzenetére
Mi a rák az a natural join?
Utána kellett néznem, mert ilyet még nem láttam.
Azt írják, hogy az SQL:2011 óta opcionális nyelvi elem, nem kötelező implementálni. (Akkor azért nem láttam eddig. )Mindenesetre arra jó, hogy a lustáknak ne kelljen kiírni a JOIN feltételeket, hanem a DB motorra bízzák az azonos nevű oszlopok összehasonlítását.
(magyarul az ON tábla1.id=tábla2.id elhagyható, vagy ha az oldschool from tábla1, tábla2 szintaxist használod, akkor WHERE mögül a tábla1.id=tábla2.id)Egyáltalán miért nem szabvány SQLt tanítanak?
Mikor BMEn különböző DB jellegű tárgyakat hallgattam, ott nagyrészt szabvány SQL volt, de megmutatták azon felül a legelterjettebb DBk szintaktikai különbségeit. (T-SQL (MS) vs PL-SQL (Oracle))Másik kérdésre meg az a válasz, hogy nincs különbség a 2 query között.
Első az oldschool formátumban van írva, amikor még nem volt szabványosítva a JOIN szintaxis, hanem minden DB kezelő a saját feje szerint toldozta-foltozta az akkor érvényes szabványt, így alakult ki a FROM után vesszővel felsoroljuk a táblákat, majd WHERE mögé kerülnek a JOIN feltételek szintaxis, amit elég sokan implementáltak anno ahhoz, hogy még ma is elterjedt legyen, emiatt az újabb DB kezelőkbe is bele szokták tenni. (Pl. SQL Server 2008-ba betették, mivel MS lőni akart a Teradata júzereire is)
Második meg az SQL92-ben definiált szabványos írásmód, amit minden DB kezelőnek ismernie kell.
Működésben nincs különbség a kettő között, mivel a DB SQL optimalizálója átrendezi a futtatandó kódot, ide-oda pakolászva a feltételeket, végül mindkettő szintaxisnak ugyanaz lesz a végrehajtási terve.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
Meg az exists egy olyan okossag, ami egesz jo hatekonysagot mutat, annak a probalgatasat is ajanlom.
Nem volt mindig így.
Tizenéve még kifejezetten kerülendő antipatternként tanították az EXISTS/NOT EXISTS párost, mivel régi DBken nagyon rosszul futottak.
Modern DBk optimalizálói viszont végrehajtás előtt át szokták alakítani LEFT JOINra, és úgy futtatják.
Szóval a
select *
from tabla1
where not exists (select id from tabla2);helyett már
select tabla1.*
from tabla1
left join tabla2
on tabla1.id = tabla2.id
where tabla2.id is null;végrehajtási tervét fogod látni, és futtatási sebességben sem lesz köztük különbség.
Régebbi/kevésbé fejlett optimalizálóval rendelkező DB motorokon viszont a második kód sokkal gyorsabban fut, mint az első.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Micsurin
nagyúr
Köszönöm! Az a baj most nem gyakorlati dologról beszélünk hanem egy zh-ról. Ott meg ha a subquerry erőltetése a feladat x-y formátumban akkor arra fog járni a pont bármennyire is életszerűtlen a feladat szaga. Emiatt nem tudom pontosabban megfogalmazni a most bugyutának tűnő kérdésem! De így, hogy csak a forma tér el valamivel tisztább köszönöm!
nyunyu Életemben először látom de magát az oracle sql-t is eddig csak mysql-lel kellett dolgozzunk, felcsesz ez a szintaktika. LIMIT helyett is mire megtaláltam ezt a ROWNUM cuccot és rájöttem, hogy subquerry megy ebbe is vagy van FETCH azt hittem megőszülök.
Majdnem jó tipped volt ez most nem BME hanem OE.Neked is köszönöm! Ergo maradhatok a JOIN-oknál és csak arra kell figyeljek milyen formában ad vissza a subq adatot és azt miképp illesztem JOIN-al.
Miért nem lehetett ezt így leírni a jegyzet vagy a ppt-ben?
Igen már az EXISTS sem "tiltott" dolog, sőt..., kicsit fura az egész... de még ez az értelmes része a tranzakciók meg ez a terminálos dolog végképp elveszi a türelmem sose akartam bigdatara menni de miután tudom, hogy oracle-öznek még annyira se mint eddig.
Köszönöm a válaszokat!
martonx Legközelebb oda fogom feldobni akkor, nem tudom jobban leírni mert egy minden gyakorlatiasságot nélkülöző PPT példa alapján kell rájönnöm, hogy mit is akarok kérdezni.
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
nyunyu
félisten
válasz Micsurin #4783 üzenetére
Alquerykről annyit érdemes tudni, hogy az SQL nyelv szintaxisa úgy van felépítve. hogy minden helyre, ahol táblanevet vár, oda lehet zárójelek közé írni egy alqueryt, és akkor annak a querynek az eredményhalmazát fogja a táblaként használni a másik művelethez.
Így tudod pl. tovább szűrni az eredményeket, vagy pl. azzal joinolni.Az mondjuk DB implementáció függő, hogy az alqueryt bezáró zárójel mögé kell-e aliast írni, vagy sem (Oraclenél kötelező, MSnél nem)
Azzal az aliasszal tudsz majd a fő queryben az alquery mezőire/oszlopaira hivatkozni, mintha egy tábla oszlopaira hivatkoznál.Tranzakciók: azt meg kell érteni, mivel egy sokfelhasználós konkurens rendszerben nem lehet élni nélküle.
Adatoknak akkor is konzisztensnek kell maradniuk, ha sokan piszkálják őket egyszerre, vagy bármi hiba beüt.
Olyan nem lehet pl. egy félbeszakadt átutalásnál, hogy a pénzt levonták a számládról, de a fogadó oldalon meg nem jelenik meg, olyankor a bank nem tárhatja szét a karját, hogy bocs rendszerhiba volt, így jártál...Terminálos dolog?
SQLPlus? Tudom, hogy a nagyvállalati rendszeradminok kedvenc perverziója, hogy SQLPlusszal futtatható releaset kérnek, majd hozzádvágják a hibalogot, hogy fejtsd meg miért nem futott le (mit írtál el benne, vagy melyik 2 query közé nem tettél /-t, vagy milyen alternatív nyelv volt beállítva a termináljának...)
de fejlesztőként minimum egy (ingyenes) Oracle SQL Developer IDEt azért elvárhatna az ember a fejlesztéshez, ugyan nem a legjobb, de mégsem az SQLPlusszal kell szerencsétlenkedni.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
nyunyu
félisten
válasz Micsurin #4777 üzenetére
Első példádban:
SELECT e.department_id, last_name, legkisebb
FROM employees e,
(SELECT department_id, MIN(salary) legkisebb
FROM employees
GROUP BY department_id) min
WHERE e.salary=min.legkisebb AND e.department_id=min.department_id;"e" néven hivatkozik az employees táblára, míg az alquery eredményhalmaza a "min" aliast kapta.
WHERE után láthatod, hogy táblanév.oszlop vagy alias.oszlop formátummal lehet hivatkozni az egyes táblák vagy alqueryk elemeire.
Vagy a SELECT mezőlistájánál is azért van kitéve az e. az első mező elé, mert mind a táblában, mind az alqueryben van department_id, és az Oracle megköveteli, hogy egyértelműen megmondd, hogy melyik oszlopra hivatkozol.
(Másik két oszlopa önmagában is egyértelmű, mivel a "last_name" csak a táblában, "legkisebb" meg csak az alqueryben van meg.)[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Louro
őstag
Egy dolog kimaradt, bár ez inkább megint oldschool és úgy tudom Oracle-nyavalya, de nagyon sokan használják még, mert a veterán kollégák "így mutatták neki".
select tabla1.*
from tabla1,tabla2
where tabla1.id = tabla2.id (+)
and tabla2.id is null;Én is jobban szeretem a könnyebb olvashatóságot, azaz a
select tabla1.*
from tabla1
left join tabla2
on tabla1.id = tabla2.id
where tabla2.id is null;Amikor inner join, sokan elhagyják az inner szót. Vagy az outer is sokszor el van hagyva. Nem left outer join, hanem csak left join. Bevallom nem is tudom mit lehetne az outer helyett írni. left inner join?
nyunyu: sql server 2008-nál még biztos kötelező volt aliast használni subquery esetén is. Lehet az újabbaknál már nem, de annál biztos kellett.
Mess with the best / Die like the rest
-
Micsurin
nagyúr
Hatalmas köszönet a két válaszért! El sem tudod képzelni milyen nagyon sokat segítettél vele!
Az az SQL*PLUS mikor megláttam azt hittem kiugrok a bugyiból ijedtemben. Rögtön felötlöttek bennem a linuxos élmények a szóközökkel kapcsolatban és a szép gondolatok, hogy itt hagyom ezt az egészet a f*ba azt mehet egy motorszerelői OKJ.
Ez van ezt kell szeretni és túlélni szerencsére csak ez az 1 adatos tárgyam van/lesz.(mert nincs az az isten, hogy én BigData-ra menjek hamarabb megyek el szoftverre, pedig hálózat vagy beágyazott rendszerekre akarok célozni. )
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
Lassan biztosan kitelik a becsületem de azért egy kérdésem még lenne, kevésbé gáz a fórumon beégni mint az előadó vagy a demó előtt a hülyeségemmel.
Ha jól értettem nyunyu akkor ezek szerint nekik ekvivalens megoldásoknak kell lenniük ugye?
Listázzuk azon dolgozók vezetéknevét, fizetését és részlegük nevét, akik többet keresnek, mint amennyi a részlegük átlagfizetése.1. ahogy én értelmeztem a feladatot, 2. ahogy meglett adva rá megoldás.
SELECT er.last_name, er.salary, department_name, át.átg FROM employees er
INNER JOIN departments ON er.department_id = departments.department_id,
(SELECT department_id, ROUND(AVG(salary),2)AS átg FROM employees GROUP BY department_id) át
WHERE er.department_id = át.department_id AND er.salary > át.átg;SELECT last_name, salary, department_name
FROM employees INNER JOIN departments USING (department_id)
NATURAL JOIN
(SELECT department_id,ROUND(AVG(salary)) részlegátlag
FROM employees
GROUP BY department_id)
WHERE salary > részlegátlag;
Próbáltam a linkelt oldalra bedobni de nincsenek meg az instertjeim hozzá (sima basic HR séma ami az Oracle 12c-ben van) és nem egészen értettem az oldal milyen PlaintText-et várna tőlem a 2. ablakban.
MINUS-al rámentem és a nagy semmit kapom vissza ha a +1 átlag oszlopom kiveszem szóval jónak kéne lennie I guess.
edit.: elsőben department_id és name javítva, csak az előzőt hagytam vágón...
[ Szerkesztve ]
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
nyunyu
félisten
válasz Micsurin #4789 üzenetére
Alapvetően jó a próbálkozásod, de az első JOIN feltétel után már ne használd a vesszőt a következő JOINolandó táblához/queryhez, hanem ott is írd ki megfelelő JOIN formulát.
(ne keverjük a régi és a szabványos JOIN szintaxist!!!)Picit olvashatóbbra rendezve:
SELECT er.last_name, er.salary, d.department_name, át.átg
FROM employees er
INNER JOIN departments d
ON er.department_id = d.department_id
INNER JOIN (SELECT department_id, ROUND(AVG(salary),2) AS átg
FROM employees
GROUP BY department_id) át
ON er.department_id = át.department_id
WHERE er.salary > át.átg;Példa megoldás gyakorlatilag ugyanez, csak nem használ benne aliasokat (amik a kód átláthatóságát, követhetőségét, érthetőségét növelik)
Ja, meg natural joint használ, csak azért hogy ne kelljen kiírnia az azonos oszlopok menti join feltételeket.[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
Micsurin
nagyúr
Akkor jó az elképzelés csak figyeljek a JOIN-ra, nagyon nagyon köszönöm!
Rákérdeztem a demonstrátornál, hogy ebben a formában elfogadható-e erősen kíváncsi leszek és erősen remélem nem ezt a NATURAL JOIN-os formát várják el mert erre nem akar ráállni az agyam nem logikus nekem az ALIAS-ok is hiányoznak.
Az ALIAS-ok elhagyására érted, hogy átláthatóbbá teszik?
Majdnem olyan rossz a hiányuk számomra mint a #MyRegion elhagyása C#-ban és az ömlesztett kódot bámulni.The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
Nagy segítség volt tényleg köszönöm!
Egy héttel zh-k előtt csak átvettem és megértettem 12 hét anyagát meg megírtam a komplett féléves beadandót...The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
Micsurin
nagyúr
válasz martonx #4794 üzenetére
Opre szerver + 2 klienses és szolgáltatásos beadandó ami páros munka lett volna egyedül toltam le mert beleszart a társam, tanárt nem láttam a félévben mindent demonstrátor tart van olyan tárgyunk (digitális rendszerek, ALU és alap tervezési feladatok) 2x tartottak konzit amúgy egy fél hiányos fél katyvasz pdf halmazból OMB módszerrel tanulj.
Nem véletlen kértem segítséget és hagytam a végére dolgot nem épp lustaságból. Szeptember 1 óta ~200 km-ert mentem motorral, mikor ügyintézni kellett beszaladnom a TO-ra vagy a városba, egy út oda és vissza ~40km.
Nem jött be...! Ösztöndíj megtartására gyúrok, leakarom cserélni a Delkevic dobot egy teljes GPR rendszerre, dob + leömlők + sport kati.
[ Szerkesztve ]
The Separatists have no regard for innocent life. They don't care who walks away from war and who doesn't. That's why we move on them now, Commander……and Wolfpack leads the hunt.
-
kw3v865
senior tag
Sziasztok!
PostgreSQL 11-et használok és törölni szeretnék minden cache-elt adatot. Miként lehet ezt megtenni? Függvényt írok, és most optimalizálni akarom a működését (emaitt sokszor le is futtatom azonos paraméterekkel, miután módosítottam a kódon), ezért azt szeretném, ha "tiszta lappal" indulna mindig. Van erre valami egyszerű, de biztos megoldás?
[ Szerkesztve ]
-
bambano
titán
válasz kw3v865 #4798 üzenetére
azt, hogy a postgresql ne cacheljen, úgy a legegyszerűbb elérni szerintem, hogy kicsire veszed a neki adott memóriát. esetleg egy fals lekérdezéssel kiszorítod az értékes adatot a ramból.
hogy az oprendszer a blokkos eszközt ne cachelje, az az oprendszertől függ.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
- Politika
- NBA és kosárlabda topic
- Bundle topik
- Summer Game Fest 2024 - Az összes bejelentés egy helyen!
- Tőzsde és gazdaság
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen okostelefont vegyek?
- LEGO klub
- Azonnali mobilos kérdések órája
- Ilyen még nem volt: sztrájkba kezdtek a Samsung dolgozói
- További aktív témák...
- Lenovo Thinkcentre M710s 7. gen i5-7500 CPU, 16 GB DDR4 RAM
- Gigabyte GA-Q77M-D2H LGA 1155 alaplap, + ajándék i5-3470 CPU
- DELL OPTIPLEX 3040 MICRO PC, i5-6500T CPU,8 GB DDR3 RAM, 500 GB HDD
- AKCIÓZVA! Lenovo ThinkBook 13s Fémházas Profi Ultrabook -60% i5-10210U 8GB 256GB SSD FHD IPS WIN10
- HP Elitebook 850 G3 i5 / 15.6" Full HD / 8Gb / 512Gb ssd / USB Type C / Win10
- Lenovo Thinkpad magyar billentyűzet E580 E585 E590 T590 P53S L580 L590 P52 P72 P53 P73
- PNY GeForce RTX 4070 Ti SUPER 16GB Verto Overclocked Triple Fan DLSS 3
- Gigabyte GeForce RTX 4080 Super Windforce V2
- Call Of Duty Modern Warfare III (2023) Cross-gen / Vault edition XBOX ONE / SERIES X Letöltőkód
- GIGABYTE GeForce RTX 4070 Super Windforce OC
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs