ovaj kod:



ispisuje:



i gotov je u sekundi.

ovo sto si napisao traje previse dugo cak i kada dodam uslov



imas li jos neki predlog?

A sta si ti ono pitao?

kako da spajanjem dve tabele dobijem samo jedan zapis (po id-u), a ne kombinaciju koja se dobija klasicnim JOIN pristupom.

da probam ovako: u jednoj tabeli je id kupca i datum kupovine.
u drugoj tabeli je id kupca i ime kupca.

kako dobiti id kupca, ime kupca i datum poslednje kupovine?

Ako sam dobro shavtio, mislis na ovo?

za sve korisnike

Koliko sam shvatio, niko nije odgovorio na ovo, a sada i meni treba :-(

Imam jednu tabelu sa ID-om, a drugu tabelu sa njegovim atributima, vise atributa za jedan ID...
T1:
ID,
Naziv,
...


T2:
ID,
Atribut
VremeUnosa


Treba mi da izlistam sve iz T1 sa poslednjim unesenim atributom
?

od T2 napraviš upit, pa ga ubaciš kao alias tebele:

Nije dobro, zapravo dobio si isto sto i inner join.

Znam sta vas zulja Lako bi resili agregacijom samo da nije tog atribut polja koje se razlikuje pa totalno unisti group by
Resenje je da prvo napravite agregaciju datuma samo po ID, bez ostalih polja i onda to joinujete sa T2 po tom virtuelnom kompozitnom kljucu.



ovo ce vratiti tabelu sa ID i poslednji uneseni atribut i vreme unosa. To sad mozete da okacite kao view radi preglednosti (pa se on joinuje na T1) a moze i da se uradi inner join na T1 direktno:



Mozda postoji i malo optimalnije resenje, ali ni ovo nije lose, ako postoji desc index na datumu i ID je PK sve se resava sa dva clustered scan-a. Dupli rezultati mogu da se pojave samo ako ima dva atributa sa istim datetime, ali onda i mora da se definise koji je vazniji od ta dva da bi se rafinisalo resenje.

ja sam razumeo da hoće i za svaki atribut.
no dobro.

radi
za'valjujem!
:)

gde je T1 glavna tabela, a T2 tabela atributa

izraz unutar OUTER APPLY evaluira se za svaki red glavne tabele (predaje mu se argument ID) i ponasa se slicno subselectu, s tim sto je neuporedivo mocniji. Subselect vraca iskljucivo skalarnu vrednost, dok je ovde moguce vratiti virtuelnu tabelu (vise kolona i vise redova).

Odlicno resenje, bez agregacije. Cak je i brze 30% od onog sto sam okacio, pod uslovom da postoji desc indeks na vremeunosa, u suprotnom je 4 put sporiji (zbog sorta).

Jeste, resenje je elegantno i performantno dok tabela ne postane prevelika. Onda troskovi, inace elegantnog Nested Lopps operatora postaju neprijatni ili cak nepodnosljivi. U tom slucaju vise se isplati uraditi JOIN, pa pokupiti samo ono sto nam treba. Optimizer ce u vezi JOIN-a izabrati optimalni pristup za velike table, sto u slucaju APPLY operatora nazalost nece - njemu je tu velicina tabele irelevantna. Ovo bi moglo da bude resenja za large table:



Na velikoj tabli treba mu mnogo manje logical read-ova, nego resenju sa APPLY.

Hm, ne vidim to. U ovom slucaju imas obavezan sort tek nakon outer join-a, sto znaci da query engine uvek mora da formira pun outer join dataset sa max t1+t2 redova da bi primenio sort i projektovao ROW_NUMBER().
Sa druge strane outer apply resenje koje si dao ce (uz postojanje desc indeksa na vremenu) uvek raditi sa t2 redova bez ijednog sorta i bez ijednog table scan-a, sve ce cupati iz indeksa. U principu oba se svedu na left outer operaciju samo u row_number() slucaju uvek vise redova dolazi iz T2 seta a where uslov ne moze da se primeni pre outer-joina jer je na projektovanom polju i samim tim ne vidim prostor za query optimizera.

Linq2Sql recimo dosta koristi tu taktiku sa ROW_NUMBER() u Take(int) operacijama jer rn omogicava sve komparativne operacije (<, >, itd), ali to mi ne deluje nikako optimalno vec vise apstraktno i univerzalno.

Izvinjavam se na zakasnelom odgovoru...

ROW_NUMBER() resenje je performantnije kada je glavna tabela veoma velika. Uz odgovarajuce indekse optimizer se za ovo resenje generisati plan sa lepim Merge Join operatorom, pracenim ne tako lepim Sort operatorom. U ovom slucaju, kao sto si ti napomenuo, Sort je najveci konzument vremena i resursa. U zavisnosti od velicine tabele atributa moze da bude od koristi da se Sort operator prebaci sa leve strane Merge Join-a (da se najpre prvo sortira druga tabel, pa tek onda joinuje).

CROSS APPLY pristup je fiksan - za svaki red iz glavne tabele potrebne su 3 ili 4 strane iz tabele atributa. resenje odlicno skalira drugu tabelu, ranjivo je, medjutim, na velicinu glavne tabele. Ako u glavnoj tabli imamo 1M redova onda ovo resenje potrebuje 3-4M logical readova.

Dakle, u ovoj trci (ROW_NUMBER resenje vs. CROSS APPLY sa 1M redova u glavnoj tabli iliti Sort vs. Nested Loops) pobednik je ROW_NUMBER() do izvesnog broja redova u drugoj tabli (recimo 1.5 M). Sto je broj redova u drugoj tabli veci, vece su sanse da drugo resenje pobedi. Imao sam u praksi takav primer i resenjem sa ROW_NUMBER() uspeli smo da poboljsamo performanse za nekih 15-20% (SSMS ce poredeci ova dva plana sugerisati da poboljsanje treba da bude preko 50%, realno je, ipak, 15-tak %).

Izvinjavam se svim zbog sturog odgovora, @mmix nadam se da sam barem delimicno odgovorio na voje pitanje. Takodje se nadam da ce okolnosti dozvoliti da u narednih nekoliko dana napisem detaljan clanak o ovom problemu, sa kompletnim test skript rutinama.

Pozdrav,
M.