TOP N

Følgende selecter de 3 første:

SELECT * FROM (
    SELECT *
    FROM tabel1
    ORDER BY index_felt
  )
  WHERE rownum < 4

Det smarte ved denne sortering er faktisk at den kun bruger tid på at sortere de første tre rækker, og dermed IKKE tager alle rækker, sorterer dem, og dernæst tager de tre første, selvom man umiddelbart skulle tro det på sql-en.

teepee> Eeeh - så er det jo ikke sorteret?

Nosjns: Hvad nu hvis rownum for alle de records, hvor x=3 (som i mit eksempel) er større end f.eks. 4?

Rownum er \"rækkefølgen\" i din cursor ikk\'?

Din select vil se sådan ud:

SELECT * FROM (
    SELECT *
    FROM tabel1
    WHERE x=3
    ORDER BY index_felt
  )
  WHERE rownum < 4

Rownum er \"rækkefølgen\" fra mit sub-query resultset. Som starter med 1 og da du skal have de 3 første (top) skal det være mindre end 4.

ok, så rownum er altså noget der genereres hver gang man selecter?

Jeg får lige prøvet skidtet af...

Rigtigt Rownum genereres for hvert select.

teepee: Hvad jeg kan læse ud af Oracles Dokumentation og hvad jeg selv har testet, er dette den rigtige måde.

Det er alle rækkerne der bliver sorteret og ikke kun de 3 første.

Du har ganske ret nosjns. Det andet eksempel er korrekt!

(Må hellere lige sige jeg testede begge dele *S*)

Rækkerne bliver sorteret ud fra index og afbrydes når den når rownum grænsen. Deror hvis du har en masse rækker a..b..c..d..e..f og disse er i index, så starter den med at sortere fra en ende af, altså a..b..c og så finder oracle selv ud af at yder-selecten ikke skal bruge flere og afbryder sorteringen af resten.

Generelt er Oarcle nødt til at sortere alle rækker selv om der kun skal returneres nogle få stykker.. Ellers er det jo ikke \"de første\" man får fat i.. :-)

psv=> Sikke noget sludder. Læs f.eks i det seneste Oracle magazine om nøjagtig denne situation. Oracle afbryder selv når den \"har fået nok\". Og så skulle jeg hilse at sige at du kan jo bare prøve at lave en order by på en tabel med eks. 100.000 rækker og dernæst lave en select af de første tre af de 100.000 rækker og se at den avancerede tager betydeligt kortere tid. Hvis du er bekymret for cachen, kan du jo lave den avancerede søgning før den simple og stadig se at den simple tager betydeligt længere tid. Med avanceret mener jeg TOP N...

Hehe - lige meget hvordan du end vender og drejer det skal du have sorteret alle 100.000 rækker.
(Eller i hvert fald have lokaliseret TOP N blandt alle 100.000)

Dvs. den sortere ikke fra en ende af som du siger... Men plukker de N første fra en i forvejen sorteret struktur!

Det er derfor der er inkluderet en order by på et index-felt.

Jep, det er netop at der står \'index-\' foran feltnavnet, der gør at det kan lade sig gøre, ellers bliver søgning gangske tung. Hvis det var en order by på et ikke-indekseret felt var der ingen vej udenom.... alle rækker sorteres og derefter udvælges de første N.

Jeg overgiver mig... :-)