Új hozzászólás Aktív témák
-
bpx
őstag
válasz bambano #3100 üzenetére
Azért, mert akkor született a döntés a napok kihagyásáról, és az Oracle meg fogta magát, és ezt vette alapul. Kipróbáltam, a területi beállításoknak erre nincs hatása, tehát én hiába állítom pl. UK-ra, attól még nem fogja az 1752-t 355 naposnak számolni, hanem ugyanúgy 1582-t mondja rövidebbnek.
-
bpx
őstag
Kell egy adatbázis job, ott van rá az adatbázis saját ütemezője. Mi a baj azzal?
DBMS_SCHEDULER helyett van DBMS_JOB is, de az a régi módszer, nem ajánlom, arról le kellene szokni.Vagy ha nagyon Windows jobot akarunk (inkább ne), akkor kb. ennyit kell beütemezni:
set ORACLE_HOME=...
set ORACLE_SID=...
set PATH=%ORACLE_HOME%\bin;%PATH%
sqlplus user/password @script.sql -
bpx
őstag
válasz #30734848 #3142 üzenetére
Hát én egy regexpet ilyenkor meg nem írok már, de a sima SQL még belefér egy hosszú nap után:
create table t1 (text varchar2(20 char));
insert into t1 values ('123456123');
insert into t1 values ('12342');
insert into t1 values ('229898012342');
select text from t1;
TEXT
--------------------
123456123
12342
229898012342
select
text,
listagg(c, '') within group (order by c) as uniq_c
from
(
select
distinct text, substr(text, level, 1) as c
from
t1
connect by level <= length(text)
)
group by
text
;
TEXT UNIQ_C
-------------------- --------------------
12342 1234
123456123 123456
229898012342 0123489 -
bpx
őstag
válasz DopeBob #3157 üzenetére
Akkor viszont:
with st as
(
select 'K10' as text from dual union all
select 'K12' as text from dual union all
select 'K13' as text from dual union all
select 'K99' as text from dual
),
data as
(
select 1 as value from dual
)
select
data.value,
st.text
from
st,
data
order by
data.value,
st.text
;
VALUE TEXT
---------- ----
1 K10
1 K12
1 K13
1 K99 -
bpx
őstag
válasz htcwanted #3336 üzenetére
Nagyon jó, már csak az adatbázis típusa kellene, mert pl. Oracle-ben ez egy sima matview és nem írunk sem MERGE-t, sem INSERT .. SELECT-et, mert azoknál hatékonyabb.
A szűrés nélküli, teljes táblára vonatkozó DELETE-et meg csak indokolt esetben használjuk, mert egyébként felesleges pazarlás. Simán TRUNCATE és kész.
-
bpx
őstag
válasz Ablakos #3356 üzenetére
RANK helyett DENSE_RANK-ot kellene használni.
Magyarázat helyett itt a különbség a kettő között, így talán érthetőbb:
ADAT RANK DENSE_RANK
---- ---- ----------
A 1 1
A 1 1
A 1 1
B 4 2
B 4 2
C 6 3
C 6 3
D 8 4
D 8 4
D 8 4
E 11 5
E 11 5
F 13 6Ezen kívül a nev és szuletesi_ido oszlopokra is szükség van.
Ja látom az már megvolt.
[ Szerkesztve ]
-
bpx
őstag
válasz Apollo17hu #3442 üzenetére
Bocsánat, de ennyi információ birtokában én is csak ennyit tudok mondani: olyat, ami gyorsít rajta. Legalább egy plant mutass, de végrehajtási statisztikákkal még jobb lenne.
-
bpx
őstag
válasz Apollo17hu #3445 üzenetére
Ha most tényleg az a cél, hogy a 2 subqueryt egymástól független megcsinálja 1-1 alkalommal, akkor kb. így:
SELECT /*+ use_hash(t1 t2) */ t1.mezo_1
,t1.mezo_2
FROM (SELECT /*+ no_merge no_push_pred */ t.id
,t.mezo_1
,t.mezo_2
FROM tabla_1 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t1
,(SELECT /*+ no_merge no_push_pred */ t.id
FROM tabla_2 t
WHERE feltetel_1
AND feltetel_2
...
AND feltetel_n) t2
WHERE t1.id = t2.id;A subquery itt úgy viselkedik mintha view lenne. A view-kat az adatbázis "kifejti" ha tudja, az eredeti példát szerintem simán átírja az adatbázis úgy, mintha nem is lennének subquery-k, csak a 2 táblára a join. Ez a view merging, ezt akadályozza meg a no_merge hint.
Ha a view-kon kívül is vannak egyéb feltételek, azt az adatbázis be tudja helyezni a view-n belülre. Pl. a "select * from view1 where column1='...'" lekérdezést végre lehet úgy hajtani, hogy előállítja a view1 teljes eredményhalmazát, majd a végén alkalmazza a column1 szűrést, de úgy is, hogy a column1 szűrést átírja úgy, mintha a view-n belül lenne. Ez nem csak egyszerű szűrésekre működik, hanem joinra is, tehát miután előállította a t1 tartalmát, az adatbázis a t2-be már beviszi a tabla_2.id = t1.id szűrést és felhasználja a t1-ből jövő id értékeket, ez a join predicate pushdown. Ezeket tiltja a no_push_pred.
A use_hash-t meg csak a biztonság kedvéért tettem oda, hogy mindkettő subquery-t csak 1-szer csinálja meg, és ne válasszon nested loops-t.
Aztán ezen kívül még lehetnek mindenféle más optimalizálások, amelyekre most nem gondoltam és további hintek kellenének.
De persze nem ezt tartom a jó megoldásnak.
-
bpx
őstag
(#3447) sztanozs
Ez tök ugyanaz, mint az eredeti.
(#3448) tm5
Ez is. Erre írja át magától az adatbázis.
Nyilván egyszerűbbek, de a kérés pont az volt, hogy ne ezt csinálja.
-
bpx
őstag
select * from (
select * from (
select
pilota, sum(pont) over (partition by pilota) as sum_pont,
vegeredmeny,
row_number() over (partition by pilota order by vegeredmeny) rn
from futam) where rn <= 4
) pivot
(min(vegeredmeny) for rn in (1 as er1, 2 as er2, 3 as er3, 4 as er4))
order by sum_pont desc;De szerintem MySQL lesz a kérdés.
-
bpx
őstag
Az első változatot irtani kell.
Nem az átalakítás a nagy munka, hanem az, hogy ha index van az oszlopon, akkor az tipikusan a tábla.dátum_mező-re van, és nem pedig a to_char(tábla.dátum_mező...)-re, így a lekérdezés nem tudja használni az indexet, teljes táblát olvas, lassú. Persze lehet function based indexet létrehozni a to_char(tábla.dátum_mező...)-re is, de erre az esetre nem ez a helyes megoldás.
Ezen kívül az ilyen átalakításoknál az optimizer számosságbecslései is pontatlanak lehetnek, hiszen dátum típusnál tudja, hogy pl. 2017-01-01 előtt a 2016-12-31 van, de ha ugyanezt stringként kell becsülni, akkor olyan értékek is lehetségesek, amelyek dátumnál nem, pl. 2017-00AAAAAA, 2016-999990000, stb.
-
bpx
őstag
válasz SunyaMacs #3650 üzenetére
select
t.topic_id,
t.topic_name,
coalesce(p.post_time, t.topic_time)
from
topics t
left join
(
select
topic_id,
max(post_time) as post_time
from
posts
group by
topic_id
) p
on (t.topic_id = p.topic_id)
;Ha meg azt akarnám, hogy gyors is legyen, akkor +1 oszlop a topics-ba, pl. last_post_time, amit post írásakor karban kell tartani, és akkor nem kell join meg aggregáció.
-
bpx
őstag
válasz Iginotus #3660 üzenetére
Az egy nem correlated subquery (magyarul még szebb: korrelált allekérdezés), ezért ami belül van, az egyszer lefut, és kívül mindenhova az ott kapott értéket használja. Lehet belőle correlated subquery-t csinálni valami értelmetlen feltétellel és akkor majd miden sorra újból kiértékelődik. Persze ez nem szép és kapásból odaírnám kommentbe, hogy ez miért van belegányolva. Vagy marad a ciklus, amit már első ránézésre is el lehet olvasni.
create table forge (row_id, code_neu) as select rownum, 0 from dual connect by level <= 10;
create table oe (orgeh_code) as select rownum from dual connect by level <= 4;
select * from forge;
ROW_ID CODE_NEU
---------- ----------
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
select * from oe;
ORGEH_CODE
----------
1
2
3
4
update forge set code_neu =
(
select orgeh_code from oe
----
where forge.row_id = forge.row_id
----
order by dbms_random.value fetch first 1 row only
)
where row_id between 1 and 9;
select * from forge;
ROW_ID CODE_NEU
---------- ----------
1 1
2 3
3 1
4 2
5 1
6 1
7 4
8 3
9 4
10 0 -
bpx
őstag
Most akkor PIVOT/UNPIVOT azért van kilőve, mert nem használható, vagy mert nem sikerült megoldani vele?
with data as
(
select * from t_test
unpivot (value for val in (val1, val2, val3, val4, val5))
)
select a, b, c from (select val, value, label from data)
pivot (min(value) for label in ('A' as a, 'B' as b, 'C' as c))
order by val; -
bpx
őstag
válasz GreenIT #3800 üzenetére
Fogalmazzunk inkább úgy, hogy az Oracle csak sokkal több pénzért tudná ezt, amit már egyre több helyen nem akarnak megfizetni, jogosan.
Kíváncsi vagyok medig tarthatják még a mostani árazást és üzletpolitikájukat.
Az infrastuktúra még elfogadható, de a support és az általuk szállított alkalmazás színvonala ezért a pénzért gyalázatos. -
bpx
őstag
válasz #74220800 #3894 üzenetére
Először azt kellene tisztázni, hogy milyen fajta SQL, mert Oracle adatbázisban nincs olyan, hogy INT(2). Olyan van, hogy INT, amit egyébként senki nem használ, vagy olyan, hogy NUMBER(2, 0). Ez megy (és akkor még a VARCHAR2 szóba sem jött):
CREATE TABLE ELSO
(MASODIK NUMBER(2, 0) NOT NULL,
HARMADIK VARCHAR(14),
NEGYEDIK VARCHAR(13),
CONSTRAINT OSZT_PK PRIMARY KEY (MASODIK));[ Szerkesztve ]
-
bpx
őstag
válasz user112 #3904 üzenetére
Erre szoktunk PIVOT-ot használni, de egy ilyen egyszerű esetben a "lábbal hajtós" megoldás is elfogadható, pl.:
select
kod,
min(Aerteke) as Aerteke,
min(Berteke) as Berteke
from
(
select
kod,
case when tipus = 'A' then ertek end as Aerteke,
case when tipus = 'B' then ertek end as Berteke
from
tabla
) group by kod; -
bpx
őstag
válasz user112 #3906 üzenetére
Lehet a MIN helyett SUM, de ebben az esetben nincs jelentősége, hogy melyik, mert csoportonként csak 1 sorban lesz érték, a GROUP BY miatt viszont muszáj valamilyen aggregate functiont használni.
Az összeget bele lehet rakni új oszlopként, simán csak pl.:
min(Aerteke) + min(Berteke) as osszeg
Vagy akár:
select
kod,
min(Aerteke) as Aerteke,
min(Berteke) as Berteke,
sum(ertek) as osszeg
from
(
select
kod,
ertek,
case when tipus = 'A' then ertek end as Aerteke,
case when tipus = 'B' then ertek end as Berteke
from
tabla
) group by kod;[ Szerkesztve ]
-
bpx
őstag
válasz soldi3r #3943 üzenetére
Szerintem otthonra, 1 felhasználós környezetbe, tanulási célra, tök felesleges az XE, amikor erre a célra az Enterprise Editiont is bárki letöltheti az Oracle publikus oldaláról, és nincsenek benne XE szintű korlátozások, és ugyanúgy egy darab RPM-ből telepíthető. Az EE .rpm 3,3 GB, az XE .rpm meg 2,5 GB, tehát hiába Express Edition, az is egy jó nagy monstrum.
OS-ből ha Linux, akkor Oracle Linux (ingyenes, csak a support fizetős), RHEL (van ingyen licenc 1 accounthoz 1 gépre), SLES (nem tudom, max 5%-ban fordul elő Oracle alatt, nagyon ritkán találkozom vele), preferencia ebben a sorrendben. Otthoni környezetben esetleg Windows (na arra nem is jött ki a legújabb XE).
A desktop Linux distro-t felejtsük el, működésre lehet bírni rajta, egy Fedora-n még könnyebben, de egy Ubuntu-n már nehezebben, de nem is ezzel érdemes foglalkozni, hanem a hasznos dolgokkal. Pl. egy Oracle Linux-on alapból megy minden a saját repo-ból és beránt minden függőséget, létrehozza a usert, beállítja a kernel paraméteretek, limiteket, stb.
Annyi még, hogy fejlesztői irányból érdekel és nem infra/DBA oldalról, akkor kb. letöltesz egy előre összerakott virtuális gépet és kész: [link]
[ Szerkesztve ]
-
bpx
őstag
válasz Ablakos #3946 üzenetére
Kb. 2,5 éve van ilyen, hogy Red Hat Developer license.
[link] Itt rányomsz a letöltésre, elkezdi letölteni az ISO-t, és továbbít egy olyan oldalra, ahol leírja, hogy hogyan telepítsd. Kb. annyi a lényeg, hogy telepíteni kell a "Developer Tools" add-ont, és ha ez megvan, a telepítés végén az RH account adatok megadása után automatikusan regisztrálja a gépet, lesz rá 1 éves licenc, lehet vele használni a RH repot, stb. 1 év után, ha lejárt, kell rá renew, szintén ingyenes [link]
Ha másért nem, nekem legalább azért jó volt, mert így legalább elérem access.redhat.com-on a Subscriber Exclusive Contentet, mert egyébként nincs semmilyen RH előfizetésünk céges szinten.
[ Szerkesztve ]
-
bpx
őstag
Mert pl. lehet, hogy tiltva van. Ennek by default 1-et kellene visszadni global és session szinten is:
SELECT @@GLOBAL.foreign_key_checks, @@SESSION.foreign_key_checks;
Ha viszont 0, akkor nem történik meg a foreign keyek ellenőrzése, és büntetlenül lehet azt megsértő adatokat bevinni.
-
bpx
őstag
válasz bandi0000 #4032 üzenetére
Ennyi erővel az árat és a darabszámot is ki lehetne tenni külön táblába, mert lehetséges, hogy különböző termékeknek ugyanannyi az egységára és ugyanannyi darabot vásároltak belőle ugyanakkor.
Ezt pl. úgy szokták csinálni, hogy külön táblába kerül a vásárlás és annak a tételei, hogy milyen termékeket vettek. Pl.:
VÁSÁRLÁS(vásárlás_id, dátum+idő)
VÁSÁRLÁS_TÉTEL(vásárlás_tétel_id, vásárlás_id, termék_id, db, ár)[ Szerkesztve ]
-
bpx
őstag
válasz dellfanboy #4129 üzenetére
Ez nem SQL, hanem PHP probléma.
$tagid, $autoid helyett $megrendelo_id, $autok_id változókat használsz a query-hez, és nem a CURDATE()-tel van baja, hanem az üres változók miatt a "(, , CURDATE())"-tel.
[ Szerkesztve ]
-
bpx
őstag
válasz Apollo17hu #4167 üzenetére
Mindenki keresi az univerzális silver bulletet, de ilyen nincs.
Ha pl. az szeretnéd, hogy az optimizer ne fejtse ki és alakítsa át ezeket, akkor használhatod a NO_MERGE és NO_UNNEST hinteket attól függően, hogy az allekérdezés az csak inline view vagy tényleg subquery.
-
bpx
őstag
válasz Apollo17hu #4170 üzenetére
Persze, mert a hintet nem oda kell rakni, hanem közvetlenül a SELECT után.
WITH
t1 as (...),
t2 as (...),
...
t20 as (...)
SELECT /*+ no_merge (t1 t2 ... t20) */ ...
FROM
t1,
t2,
...,
t20,
() as tx
WHERE
tx.mezo = t1.mezo(+) AND
tx.mezo = t2.mezo(+) AND
...
tx.mezo = t20.mezo(+)Vagy bele az inline view-ba:
WITH
t1 as (SELECT /*+ NO_MERGE */ ...),
t2 as (SELECT /*+ NO_MERGE */ ...),
...Ha azt akarod, hogy gyűjtse ki tempbe az egyes CTE-ket, akkor meg MATERIALIZE hint, pl.:
WITH
t1 as (SELECT /*+ MATERIALIZE */ ...),
t2 as (SELECT /*+ MATERIALIZE */ ...),
...De ez még mindig csak találgatás, plant kellene nézni futásidejű statisztikával.
-
bpx
őstag
válasz Apollo17hu #4340 üzenetére
Na nem, annyira tudtam már tegnap, amikor olvastam az XE-t, hogy ez lesz.
Az Oracle a 12.1-től (6 éve) bevezette a container database architektúrát, de senki nem használja, mert extra licenc költsége van, de nincs akkora hozzáadott értéke, hogy megérje.
Ehhez képest az Oracle, amit csinál az XE-vel meg a Developer VM-ekkel, az az öntökönrúgás kategória, erőlteti a container database-t, miközben ha egy kezdő bármilyen problémára rákeres neten, még mindig a nem container database-es megoldásokat látja, vagy gányolást.
Nem, te a root conatinerbe léptél be, és common usert próbáltál létrehozni (ehhez kell a C## prefix), erre nem az a megoldás, hogy lefuttattod az 'alter session set "_oracle_script"=true;' és úgy hozod létre a usert, csak sajnos az itt kapott hibára ez a Google első találat. Meg ugye rögtön DBA role csak a belépéshez, hogyne.
Pl. egy SQL Server-es analógiával élve: a masterdb-be gányoltál bele és oda készülsz betölteni user adatokat.
Csak az SQL Servernél már régóta van masterdb és mellette más adatbázisok, mindenki tudja mit hova tegyen (remélem), az Oracle-nél meg még csak most terjed ez az architektúra.
Nem, ilyet nem csinálunk, eleve rossz helyre csatlakoztál. Neked nem a root containerhez kell csatlakozni (service = xe), hanem az automatikuson létrehozott pluggable database-hez (service = xepdb1), és azon belül kell dolgozod. Persze ezt még a Oracle a saját doksijában sem írja le normálisan, ott is a root containerhez való csatlakozást mutatja példának.
Ez nem a te hibád, egy kezdő ezeket nem tudja, de a doksi nem jó, a Google meg a régi módszereket adja megoldásnak.Ha Oracle adatbázissal akarsz foglalkozni, akkor mondom, hogy mit ajánlok.
Elfelejted az XE-t, az Enterprise Edition is letölthető, arra ingyen használható, hogy otthon egyedül tanulj rajta (és az XE is egy több GB-os monstrum).
Magamnak a host OS-re sem telepíteném (meg Windowsra sem). VirtualBox, abba egy Oracle Linux, és arra mehet a 19c EE telepítése.
Ehhez alapvető Linux, virtualizáció, networking ismeretek kellenek, ha ez hiányzik, akkor simán csak telepítsd fel a gépedre és használd ott.
Az adatbázis létrehozásánál pedig ne válassz container database-t, és ha nem akarod magad tovább szivatni, akkor General Purpose template-ből csinálsz adatbázist. Ilyet egy valós rendszeren nem csinálunk, de most pont jó lesz arra, hogy felrakjon minden szemetet, ami a sample schema-khoz kell. Ugyanitt még ne válassz ki semmilyen sample schema hozzáadást.
A sample schema-k teljes halmaza már nem jön az adatbázissal, azokat githubról lehet letölteni és utólag telepíteni.[ Szerkesztve ]
-
bpx
őstag
válasz Apollo17hu #4342 üzenetére
Ha az XE helyett felraksz egy EE-t, akkor lesz lehetőséged olyan hagyományos típusú adatbázist létrehozni, amit mindenki más is használ, és amivel a felesleges szívástól megkíméled magad. Kivéve, ha a CDB/PDB világ érdekel.
Az XE-nek saját kísérletezős vagy development környezetben nem látom értelmét. Erre az EE is letölthető és használható licenc nélkül, és abban legalább nincsenek korlátozások.
-
bpx
őstag
válasz BuktaSzaki #4419 üzenetére
Tipikus probléma, hogy a JDBC driveren keresztül nem működik a futó query megszakítása.
Azt most ne kérdezd, hogy melyik verzió és milyen csillagállásnál gond, mert nem tudom, régi verziónál szokott baj lenni vele. SQL Developerben is akkor működik megbízhatóan, ha JDBC helyett Oracle kliens van használatban.[ Szerkesztve ]
-
bpx
őstag
Konstans értéket nem kell a group by-ban felsorolni.
De, tud alias alapján rendezni.
Nem, nem tud oszlopszám szerint csoportosítani.select
1 + 2 as harom,
null as ertek2,
created as letrehozva,
sum(user_id) as valami,
count(*) as darab,
'hello' as ertek3
from
dba_users
group by
created
order by
harom,
letrehozva
;
HAROM E LETREHOZVA VALAMI DARAB ERTEK
---------- - ------------------- ---------- ---------- -----
3 2020-04-16 19:04:45 6442450869 6 hello
3 2020-04-16 19:04:46 13 1 hello
3 2020-04-16 19:06:12 43 2 hello
3 2020-04-16 19:06:18 23 1 hello
3 2020-04-16 19:07:31 2147483638 1 hello
3 2020-04-16 19:08:08 36 1 hello
3 2020-04-16 19:15:29 48 1 hello
3 2020-04-16 19:15:31 49 1 hello
3 2020-04-16 19:15:37 101 2 hello
3 2020-04-16 19:18:29 61 1 hello
3 2020-04-16 19:18:41 62 1 hello
3 2020-04-16 19:20:21 70 1 hello
3 2020-04-20 20:51:53 73 1 hello -
bpx
őstag
Ezek az Oracle saját tanfolyamai. Mindenhol ennyi lesz az ára nagyságrendileg és a tananyag is ugyanaz lesz. Az Oracle Hungary az oktatási részlegét leépítette, az oktatási partnerek tartják nekik a tanfolyamokat.
Több helyen is vannak egyedileg egyeztetett tematikájú ás formátumú oktatások is. Ezek ár/értékben kedvezőbbek. Talán.
De igazából egyik változattal sem vagyok megelégedve.
Az említett Webváltónál dolgozom, 10 éve. Nem foglalkozom oktatással, csak ha nagyon muszáj.
-
bpx
őstag
Egy indexet több módon lehet használni.
Az oszlop1 like 'valami%' szűréshez megy az index range scan az oszlop1-en levő indexen. Ez hatékonyan működik.
Az oszlop1 like '%valami%' szűréshez szintén használható az oszlop1-en levő index, csak az már nem index range scan, hanem index fast full scan lesz, ahol az adatbázis a teljes indexet végigolvassa random sorrendben.
Az oszlop1 like '%valami%' szűréshez ha még egy order by oszlop1 is van, akkor pedig index full scan is használható, ahol az adatbázis a teljes indexet végigolvassa, de a fa struktúrát bejárva, rendezett sorrendben.
Tehát nem, nem lesz mindig full table scan, mert a 300 oszlopot tartalmazó táblára történő full scan helyett még mindig gyorsabb a csak 1 oszlopot tartalmazó és ezáltal sokkal kisebb méretű indexen a full scan.
De az utóbbi 2 már nem hatékony és ha nagy mennyiségű adaton kell szöveges keresést végrehajtani, akkor a like '%valami%' helyett ott van az Oracle Text a saját indexeivel és függvényeivel, meg a többi adatbázisnál is a text alapú indexek és keresések. -
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.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Lenovo P1 Gen2, 15,6" FHD IPS, I7-9750H CPU, 32GB DDR4, 1TB NVMe SSD, T1000 4GB VGA, WIN 10, Számla,
- RGB MAGYAR ! ASUS ROG STRIX GL703 - 17.3"iPS , i7, GTX1060-6, 16DDR4 / 256 NVMe +1TB +garancia +SZLA
- ASUS TUF F15 FX506- 15,6"FHD 144Hz - i5-11400H - 8GB - 512GB - RTX 3050 Ti - Win11 - 2 év garancia
- HP Z620 és Z820 dupla processzoros gépek, akár E5-2690v2 20 mag, i7-11700 erősség 64 Gb RAM
- Új 2K Gamer PC Ryzen 7 5700X/ RTX 3070 8Gb/1Tb M2/2x8Gb Fury DDR4 3200Mhz/700W 2-3 Év Gar
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs