Keresés

úgy értem group by nélkül :)

De külső tábla egyébként is beszűri arra az id-re, azon belül a MAX(adat) elég önmagában.

(F1DO írására vonatkozott a kérdés, nem a tiedre)

a group by azért kell, hogy id-nként csak egy sorunk legyen. az azonos id-k egy group. a max(adat) a groupon belül a legnagyobb adatot adja vissza. a max(id) felesleges, hiszen a groupban csak egyféle id van. a distinct is felesleges, a group by miatt minden sorban más lesz az id.

Vajk

köszi, ezt eddig nem ismertem

miért kell bele a DISTINCT és a GROUP BY?

merge into B target using (select max(adat) adat, id from a where adat is not null group by id) source

on (target.id=source.id)

when matched then set target.adat=source.adat;

Így lefut (korrelációs update) 

update table B
set
( B.id,
B.adat
) = (SELECT DISTINCT
max(A.id),
max(A.adat)

FROM table A

WHERE A.id = B.id
AND A.adat is not null

GROUP BY A.id,
A.adat
)
WHERE (B.id) IN (SELECT A.id
FROM table A
WHERE A.adat is not null
);

Szolgáljon tanulságul, kedves egészségetekre! :-)

Így nem fut le, a hiba ugyanaz:

update table B
set
( B.id,
B.adat
) = (SELECT DISTINCT
max(A.id),
max(A.adat)

FROM table A,
table B
WHERE A.id = B.id
AND A.adat is not null

GROUP BY A.id,
A.adat
);

Ha jól értem (B) 1 - n (A)  és (A) -t UPDATE-eled, akkor nem szabadna ilyen hibát kapnod, mivel (B)-ben csak egyet találsz hozzá.

Egyébként ha tényleg többes kapcsolatból szeretnél, mert nincs egyértelmű kapcsolat, akkor próbáld pl MIN/MAX függvényt.

Szerintem eke, traktor és konyhasó lenne most jó.

Sziasztok,

egy újabb kérdés (elakadás) amire hátha van jó meglátásotok...

UPDATE-elés, 'A' tábla id-ja = 'B' tábla id-jával.

Ugyanakkor 'A' táblában több rekord van ugyanazon id-ra mint 'B' táblára. 

'B' tábla adataival kellene 'A' tábla rekordjait updatelni, ahol A.id = B.id

Nem fut le az update: ORA-01427 - 'egysoros allekérdezés egynél több sorral tér vissza' hibával.

Mégis hogy lehetne 'megerőszakolni' a dolgot és beupdateltetni az 1:N kulcsolású táblánál az oszlopokat?

Köszönöm, igen, visszamenőleg visszaírva - updatelve a forrás adatokat sikerült, és jó is lett..

Sikerült végül?

Ha nem, akkor tényleg jó lenne egy példa :)

Ha jól értem, akkor valami ilyesmire gondolsz. Nem túl szép megoldás a manuális oszlophozzáadások miatt, de elvileg működik, 4 sort, hárommá alakít, forrásmegjelöléssel:

create table FirstTable (Id int, First01 varchar(20), First02 varchar(20))
create table SecondTable (Id int, Second01 varchar(20), Second02 varchar(20))

insert into FirstTable values (1, 'Alma', 'Korte')
insert into FirstTable values (2, 'Szilva', 'Banan')


insert into SecondTable values (1, 'Zsiraf', 'Majom')
insert into SecondTable values (3, 'Pingvin', 'Hal')

select Id, max(First01), max(First02), max(Second01), max(Second02), max(FirstSource), max(SecondSource) from (

select Id, FirstTable.First01, FirstTable.First02, null as Second01, null as Second02, '1' as FirstSource, '0' as SecondSource from FirstTable

union

select Id, null as First01, null as First02, Second01, Second02, '0' as FirstSource, '1' as SecondSource from SecondTable) tbl group by Id

1    Alma    Korte    Zsiraf    Majom    1    1
2    Szilva    Banan    NULL    NULL    1    0
3    NULL    NULL    Pingvin    Hal    0    1

Köszi a segítő szándékot, elvileg ahogy utóbb leírtam, egy külön összesítő táblát létrehozva, majd 2 lépésben a leírásnak megfelelően beinsertálva és updatelve az adatokat úgy gondolom megoldható a dolog. 

ha mégsem akkor jelentkezem.. :-)

muszáj írj egy példát hogy hogyan néz ki az eredmény. még azt sem látom hány oszolopa van.

Az adott id-ra minden táblában létezik legalább 1 rekord.
van amelyikben 10 rekord van hozzá, van amelyikben pl 3.

Az oszlopszerkezet ugye eltér.

Ahol az adott id-ra és az adott (ezen táblához tartozó) oszlop szerkezetre lejön 10 rekord, ott ebből lejön mind a 10, mindegyik 1x, és a másik táblából amiben csak pl 3 rekord van az id-hoz ott meg nem határozottan ismétlődven lejön a 3 rekord.
ez alapján végeredményben mindenhol minden oszlopban lesz adat.
Ebben a konkrét példa esetben azt kellene megjeleníteni az adott id-hoz összesen tartozó 10 rekordon, hogy a 10, egyedi rekordot tartalmazó táblából származik adat, ergo ennek a táblának a neve szerepel egy 'adatforrás' oszlopban

és így tovább a többi esetekben.

ebből eredően persze hogy mindenhol ki lesz töltve mindegyik rowid... hiszen ismétlődik még ott is ahol nincs adat eredetileg.. ott be fogja húzni az ismétlődő rowid-t..

Logikai bukfencnek tűnik a dolog, - legalábbis 1 menetben nem oldható meg..

Először is a 3 táblát összesítő táblában külön táblánként insertálni kell a rekordokat, és ahol amelyik oszlopra nem lesz adat a táblából az üresen marad - így egyben egyértelműen megmondható hogy mely táblából származik az adott rekord. Majd 2. lépésben az üresen maradt oszlopokat updateljük, és így kitöltötté válik a tábla - az eredeti rekord származás mutatása mellett.

Ja és a rekord honnan származik részt sem értem, sajnos. Ha mondjuk ilyen lekérdezésem van:

SELECT e.empno,d.deptno FROM emp e, dept d

WHERE e.deptno=d.deptno;

akkor mit értesz azon, hogy melyik rekord honnan származik?

> A táblákban ugyanazon ID-ra/kulcs-ra eltérő a rekord darabszám.

Nagyon félek, hogy ez azt jelenti, amit gondolok, hogy jelent... vagyis hogy az a dolog, amit kulcsnak nevezel, az nem kulcs.

Sziasztok,

elakadtam egy problémában, hátha útba tudnátok igazítani, bár nem lesz egyszerű vázolni miről is lenne szó..

A feladat:

Adott 3 tábla - a közös kulcsot kivéve 3 különféle oszlop / adat tartalommal.

A táblákban ugyanazon ID-ra/kulcs-ra eltérő a rekord darabszám.

A 3 tábla összes oszlopát vízszintesen 'kiterítve' egyszerre meg kell jeleníteni és minden tábla minden rekordja le kell jöjjön a query eredményében.

Ebből eredően - mivel ugyanazon id-ra a a táblákból eltérő darabszámú  rekord jön le - ahol amelyik táblában az adott oszlopra nincs adat, ott ismétlődően jelenítse meg az adott kulcshoz tartozó rekordjait. (left join)

Mindemellett egy külön oszlopban legyen feltüntetve, hogy az adott rekord EREDETILEG melyik táblából származik! (rowid alapján?)

Ha alapból lehívom a rowid-kat azok a left join miatt ugyanúgy minden rekordon lejönnek és nem tudom hogyan, milyen eljárásban lehetne beazonosítani származásukat (hiszen mindenhol minden rowid lejön...)

10.2.0.1.0 -es DB

korábban volt itt szó a logolásról

... LOG errors INTO ...

ezzel kapcsolatban 1 kérdés:

DELETE vs ORA-02292: integrity constraint (********) violated - child record found   esetén mitől függ, hogy bekerül-e a hiba táblába?

úgy tűnik, ha a child egy másik táblában van, akkor elvártak szerint működik, ha ugyanabban a táblában, akkor viszont továbbra is csak a hibát írja ki, és nem kerül a táblába.

queryk optimalizáltak, használnak indexet rendesen?

önmagukban pár milliós táblák nem feltétlen okoznak lassú futást, de néha igen cifra dolgokat művel az optimizer

a korábbi lassú CREATE-es kérdésednél a WITH tabla AS ()  nem jöhet szóba?

Köszi,

Egyébként nem kell sokszor a teljes folyamatot végig futtatni -  viszont amikor kell akkor órákig fut kliens oldalról az alap adathalmaz leválogató query - amivel további folyamatok vannak és ilyenkor jön képbe a táblásítás - inkább, minthogy egymenetben ki tudja mennyi ideig futna le az egész folyamat.

(hogy miért fut órákig annak taglalásába nem mennék bele, részben mert nem kis cégről van szó és olyan forrástábláiról amik naphosszat fullon használva vannak tranzakciókkal.)

érdemes beleírni. ebből tudja a gép hogy ha lehet akkor többszálon kell futtatni. az admin meg szépen beállíthatja akár globálisan a limiteket akár userenként, akár userenként napszakonként.

Vajk

Pontosan hányszor kell ilyen táblát létrehozni? Mert ha rendszeresen,  akkor ott talán tervezési hiba van.

Ezesetben kliens oldalról van értelme egyáltalán ilyet beleírni a querybe?

Ennek beleírása nélkül nem használja ki a maximum futtatási szálat a kliens?

pontosan azért, mert nem a kliens dolga eldönteni. a kliens beleírja hogy parallel 4, a dba meg eldönti hogy valójában mennyit enged.

Vajk

Köszönöm, ezek a V és DBA kezdetű nevű táblák jogosultság hiányában nem elérhetőek..

Elvileg vannak ilyen nézetek, pl. v$osstat, és talán where stat_name='NUM_CPU_CORES', de nem erre kellene alapozni. Mi van az adatbázis többi párhuzamos feladatával? A hoston futó többi adatbázissal? Az egyéb szolgáltatásokkal?

Amúgy talán van a parallelnek auto paramétere az általad használt verzióban, azzal is próbálkozhatsz. De nagyon meglep, ha ez sokat számít, mivel a CTAS-od volt sokkal lassabb, mint a sima select, ami számomra nem arra utal, hogy a CPU a szűk keresztmetszet. Persze ott vannak az eszközök az adatbázisban (csak győzzed kitalálni, melyiket van jogod használni) és a op'rendszeren ennek a kiderítésére.