[SQL Server] "limit offet, max" equivalent

[Verwijderd]

Gezocht, maar niet gevonden. Hoe kan je in sql server (8.00) een limit offset, max specificeren? Voor zover ik weet kan je alleen de top x rijen selecteren (select top 10..)

Er moet toch een manier zijn om bijv recordset 50 t/m 100 op te vragen? Ik had een paar voorbeeldjes op het net gevonden met subquery's maar om 1 of andere vage reden werkten die niet

[stean]

begrijp je niet helemaal maar uuh "maxrows=100" en dan naar de 50 gaan door middel van een for-loopje ?? was maar een idee.

[Verwijderd]

hmz... Heb zelf een beetje zitten vogelen en heb het antwoord al gevonden:

code:

select top 5 * from table t1
where t1.field in(
select top 10 t2.field from table t2
ORDER BY t2.field ASC)
ORDER BY t1.field DESC

bedankt voor uw aandacht

[Verwijderd]

Op donderdag 31 januari 2002 09:02 schreef stean het volgende:
begrijp je niet helemaal maar uuh "maxrows=100" en dan naar de 50 gaan door middel van een for-loopje ?? was maar een idee.

Is idd een oplossing, maar niet de meest optimale... Stel dat je recordset 5000 t/m 5050 wilt hebben, selecteer je er 5000 voor niks.

In mysql kan je bijv de volgende query uitvoeren:

select * from table limit 50, 100 (of 100, 50; weet het ff niet meer)

En die returnt resultaat 50 t/m 100 terug... In sql-server zit die optie blijkbaar niet en moet je met ingewikkelde subquery's gaan werken

[Nielsz]

Op donderdag 31 januari 2002 09:09 schreef KoekenBoes het volgende:

[..]

select * from table limit 50, 100 (of 100, 50; weet het ff niet meer)

En die returnt resultaat 50 t/m 100 terug... In sql-server zit die optie blijkbaar niet en moet je met ingewikkelde subquery's gaan werken

limit 50,50
Je begint op record 50, en leest er dan 50 in

[Verwijderd]

jep, dat was 'm

/me z'n geheugen is weer opgefrist

[Verwijderd]

Op donderdag 31 januari 2002 09:09 schreef KoekenBoes het volgende:
[..]
Is idd een oplossing, maar niet de meest optimale... Stel dat je recordset 5000 t/m 5050 wilt hebben, selecteer je er 5000 voor niks.

Die moeten ALTIJD worden gefetched! De engine weet anders niet wat het 5001e record is. Dus het maakt qua performance geen moer uit. SQLServer bepaalt eerst de keys van de te fetchen rows en daarna pas de rows, kijk maar naar die execution plans

In mysql kan je bijv de volgende query uitvoeren:
select * from table limit 50, 100 (of 100, 50; weet het ff niet meer)
En die returnt resultaat 50 t/m 100 terug... In sql-server zit die optie blijkbaar niet en moet je met ingewikkelde subquery's gaan werken

Het zou me niets verbazen als MySQL dit deed:

- Creeer temptable met hetzelfde format als resultset + 1 keyfield extra, die op 0 begint en oploopt (identity)
- Insert de complete resultset in die temptable
- select rows uit die temptable mbv het extra keyfield.
- kegel de temptable weg.

Hetgeen je ook in SQLServer kunt doen. Je kunt dus een temptable maken met daarin de keys voor je rows + een identity field. En select daaruit je subset. Omdat een temptable blijft bestaan per connectie kun je dit gebruiken voor je searchresultpage (dus elke keer een subset uit die temptable selecten), want daar is dit voor neem ik aan?

[Verwijderd]

klopt, blijft toch de overhead om met een looptje door al die recordsets heen te lopen tot je bij je offset bent.

Het is oa voor een search-engine, voornamelijk om data over meerdere pagina's te kunnen splitten

[Verwijderd]

Op donderdag 31 januari 2002 10:34 schreef KoekenBoes het volgende:
klopt, blijft toch de overhead om met een looptje door al die recordsets heen te lopen tot je bij je offset bent.

Nee natuurlijk niet, want je hebt die extra index geinsert in die temptable die begint bij 1 en oploopt per record. Dus je kunt dan:
SELECT * FROM temptable WHERE Idx > 50 AND Idx < 100

doen oid.

Het is oa voor een search-engine, voornamelijk om data over meerdere pagina's te kunnen splitten

Hou rekening met het feit dat je dan elke keer de zoekquery opnieuw uitvoert! beter is gewoon het resultaat storen en dmv een extra key (hierboven die Idx) de subset er in 1 keer uitselecten.