- Samsung Galaxy A54 - türelemjáték
- Netfone
- Mobil flották
- Fotók, videók mobillal
- One mobilszolgáltatások
- Yettel topik
- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy A56 - megbízható középszerűség
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
Új hozzászólás Aktív témák
-
nyunyu
félisten
válasz
Micsurin
#4818
üzenetére
GRANTolni csak az tud, akié a tábla, vagy kapott rá GRANTolási jogot, vagy DBA júzer.
Akinek csak olvasási/írási joga van, az nem tudja azokat továbbadni!Ha hr séma/júzer alatt hoztad létre a táblákat, akkor hr júzerrel kell kiadni a GRANTokat.
Utána a többi júzer select * from hr.táblanév;-vel fogja elérni őket.
Egyébként a táblák listája nyilvános, bárki lekérheti a select * from dba_tables;-t.
Ha a select * from all_tables;-t kérdezed, ott csak azokat mutatja az Oracle, amikhez az aktuális júzernek joga is van. -
tm5
tag
válasz
Micsurin
#4812
üzenetére
Még annyit érdemes tudni a többiek által leírtakon túl, hogy van egy TRUNCATE TABLE parancs, ami ugyanúgy kitöröl mindent egy táblából mint a DELETE parancs, csak DDL utasításként viselkedik, tehát azonnal végrehajtódik és nem is lehet rollback-elni. A DELETE-et a tranzakción belül még igen. Cserébe villámgyors. A DELETE az sok rekordra nagyon lassú tud lenni.
-
nyunyu
félisten
válasz
Micsurin
#4804
üzenetére
Egy tranzakcióban futó adatmanipulációs (DML) utasítások (insert, update, merge, delete...) hatását csak az őket futtató DB session látja, amíg a tranzakció nincs commitálva.
Mittudomén, van egy táblád, amiben van 10 rekord.
Nyitsz egy adatbáziskezelő ablakot, amiben kiadsz 5 insertet, meg 3 updateet, majd kiadsz egy select count(*) from tabla;-t, akkor az ott 15-öt fog mutatni.
Közben nyitsz egy másik ablakot, egy ott kiadott select * from tabla; az eredeti állapotot, 10 rekordot fog mutatni, a még nyitva lévő tranzakcióban hozzáadott ötöt, meg az updateek hatását nem!
Ha az első ablakban kiadsz egy commit;-ot (amivel véglegesíted az addig nyitott tranzakcióban futtatott DML utasítások hatását és lezárod a tranzakciót), akkor a második ablakbeli select *-ot újrafuttatva már 15, módosult rekord fog megjelenni.
Ha az első ablakban commit; helyett rollback;-et nyomsz, akkor teljesen eldobódik a nyitott tranzakcióban futtatott DMLek hatása, és visszaáll az eredeti állapotra.
Tehát ha utána kiadnál egy select *-ot, akkor ugyanazt a 10 eredeti rekordot látnád az első ablakban is, mint korábban a kettes ablakban.Adatdefiníciós (DDL) utasítások (pl. tábla létrehozás, eldobás, oszlop hozzáadás, index létrehozás...) mindig önálló tranzakcióban futnak és azonnal commitálódnak, így azok nem vonhatóak vissza kiadás után.
Meg ha jól rémlik, akkor az adott DB sessionben még függőben lévő tranzakciót is commitálják!Savepointokat még nem használtam, de ahogy olvasom arra jó, hogy rollbacknél meg lehessen mondani, hogy ne az egész addigi tranzakciót dobja el, hanem csak a savepoint után futtatott utasításokat.
Lehet, hogy valakik szerint ez jó ötlet, de alapvetően sérti a tranzakciók atomiságát, és jóval nehezebb egy félig lefutott tranzakció által elcseszett adatokat javítani, mint ha eldobnád az egészet a francba, és javítás után elölről újrafuttatnád az egészet.
-
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.
-
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.) -
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. -
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.
-
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.
-
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. 
-
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Na jó, megértem, hogy a motor szerelés izgibb...
De itt nem a megszokott demo srácok tartották a labort és a tanárt aki beugrott nem igazán értettem. 
Új hozzászólás Aktív témák
Hirdetés
- Microsoft Edge
- Samsung Galaxy A54 - türelemjáték
- Luck Dragon: Asszociációs játék. :)
- Kuponkunyeráló
- Arch Linux
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- Milyen TV-t vegyek?
- sziku69: Szólánc.
- Debrecen és környéke adok-veszek-beszélgetek
- További aktív témák...
- DDR5 GAMER PC: Új RYZEN 7 8700F/9700X +RTX 4060/5060/4070/5070 +16-32GB DDR5! GAR/SZÁMLA/50 FÉLE HÁZ
- Dell Latitude 7410 Strapabíró Ütésálló Profi Ultrabook 14" -80% i7-10610U 16/512 FHD
- Szép! HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 32/512 Iris Xe FHD Magyar
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 8/512 Iris Xe FHD Magyar
- 512 Gb-os NVME-k
- LG 65" C1 OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
- BESZÁMÍTÁS! 2TB Kingston KC3000 NVMe SSD meghajtó garanciával hibátlan működéssel
- AKCIÓ! ASUS STRIX B650E-E R7 7700 64GB DDR5 1TB SSD RTX 3080 10GB Thermaltake Ceres 500 850W
- BESZÁMÍTÁS! Gigabyte A620M R5 7600 32GB DDR5 512GB SSD RTX 4070 12GB ZALMAN S2 TG EVGA 650W
- BESZÁMÍTÁS! 1TB Western Digital SN850X NVMe SSD meghajtó garanciával hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged