Finns det något vettigt pagingsystem att använda sig av till forum, gästböcker osv?
De flesta script jag har sett hämtar alla posterna till ett resultset och skriver bara ut de poster som ska synas på den aktuella sidan men det känns som om det kommer att bli långsamt efter ett tag.

I MySql kan jag fråga databasen efter x poster i "mitten" av sorteringen, t ex posterna 25 - 30 sorterat efter datum. Finns det inget liknande i MSSql eller Access?

Jag föreslår att du testar funktionen GetRows, den är klockren.
Hämtningstiden är minimal och du jobbar med vektorer, går klockrent, snabbt och smidigt.

Kolla om det inte redan finns en artikel om getRows, annars har jag ltie tips, vet bla att 4guysfromrolla.com har en suvve artikel om det.

Inte riktigt vad du var ute efter, det finns ett annat alternativ, kör man SQL Server har 4guysfromrolla.com även ett exempel med en Store Procedure som gör exakt det du efterfrågar. Du anger vilken sida du vill hämta och den returnerar ett recordset med posterna för just den sidan, du anger oxo hur många poster det ska vara på varje sida...

Hur löser MySQL detta? Kan du ge exempel på hur en SQL-sats ser ut där detta görs. Då ska jag gärna verifiera om samma SQL-sats fungerar i MS-SQL.

Detta går ju att lösa på olika sätt, enklast är ju om man har en Identitykolumn som ökar med 1 och i vilken man inte tillåter delete:s. Då är det ju bara att skriva :

SELECT TOP 25 * FROM tabell WHERE ID>=100

för att få raderna 100-124. Men en lösning som fungerar på alla tänkbara tabeller, med olika typer av index och sorteringar blir nog ganska komplex och kanske kräver temp-tabeller och/eller cursors för att selektera ut datan. Den blir nog rätt slö i många fall, men prestanda är ju relativt...

Hur som helst, vore kul att se MySQL:s syntax för detta...

/Per Hultqvist

MySQL använder ett nyckelord som heter LIMIT, vilket inte finns i SQL Server (eller ANSI SQL) och alltså inte fungerar där. Hur det egentligen fungerar i MySQL är iofs lite intressant..

I SQL Server kan man absolut göra som du föreslog, med rätt index så är det inga problem. Naturligtvis kan det bli problem med andra operationer, eller så kan andra operationer göra att det inte går att lösa på detta sätt, men om man bara vill lösa just detta problem är det bara att lägga ett index på den kolumn man vill 'bläddra' i. Naturligtvis är det absolut bäst om du har en obruten sekvens av heltal att göra TOP mot, precis som Hultan föreslog. Har man inte det kan man antingen skapa sig det genom att selecta in raderna i en temptabell (med en identity-kolumn i denna nya temptabell) vilket ger en obruten sekvens man sedan kan köra TOP mot, eller göra som jag skrivit i ett tips på min site:

http://hedgate.editthispage.com/2001/04/30

/C

Tack för info:n om LIMIT, jag misstänkte att MySQL hade någon specialare här för jag har aldrig hört talas om detta förut (och jag håller nästan uteslutande på med MS-SQL).

Jag funderade lite på det exemplet som du länkade till. Den inre SQL-satsen kommer ju att returnera fler och fler rader ju längre fram man stegar och det borde leda till en hel del NOT-IN-jämförelser om det handlar om tusentals rader. Å andra sidan så lär väl inte en temp-tabell heller vara så snabb. Vet du något om vad som händer med den SQL-satsen när antalet rader är mycket stort? Kommer den alltid att vara snabbare än en temptabell-lösning? Det känns spontant som att en subfråga som väljer ut indexen (om än mot en temptabell) som ska hämtas måste vara grymt mycket snabbare än en subfråga som väljer ut indexen som INTE ska hämtas om antalet rader är stort och urvalet är litet. Tankar kring detta?

/Per Hultqvist

NOT-IN lösningen blir seg som sirap i längden.

GetRows() presterar bättre än traditionell paging (adodb.recordset) upp till ett par tusen poster. Därefter presterar adodb.recordset (traditionell paging) likvärdigt eller bättre.

LIMIT funktionen i mySQL blir oxå seg när man närmar sig slutet av posterna.

Faktum är att man inte "bör" se till att mer än kanske 500 poster returneras som max. Har man flera hundra tusen poster så ska en bra sökfunktion finnas för att kunna gallra ut vilka poster man vill returnera.

just my $0.02

PatrikB

Håller med i det mesta, framförallt att man inte bör bläddra hur långt som helst. Kan tänka mig att LIMIT-funktionen blir seg, eftersom den förmodligen fungerar på något liknande sätt. Jag tycker aldrig att man ska använda varken recordset-paging eller getrows eftersom jag inte vill skicka extra data från servern till klienten eller använda server-side cursors. Naturligtvis finns det undantag, ex. enanvändarapplikationer som kör mot en lokal databas, men det är normalt sett inte det som diskuteras här (framförallt inte i ASP - Allmänt forum). Visst blir NOT IN-lösningen seg efter ett tag, men man bör som sagt inte bläddra för långt. En bättre lösning visat jag i ett separat svar på Hultans inlägg. Jag tycker i vilket fall som helst att man så långt som möjligt ska lösa det i databasen (eller möjligen ett system specifikt för det, dvs ett söksystem).

Du har rätt i att man kan skriva om NOT IN till en bättre lösning, se nedan. Dock vill jag påpeka att man ska alltid testa olika varianter, bara för att en lösning fungerar bra i ett exempel eller specifikt fall så behöver det inte innebära att den gör det i ett annat fall. I vissa fall är t ex en temptabell kanske bättre. Här är iaf en bättre SELECT-sats än den som gör NOT IN. Tack för påpekandet.

SELECT * FROM (
SELECT TOP 20 OrderId, OrderNumber, OrderDate
FROM (
SELECT TOP 620 OrderId, OrderNumber, OrderDate
FROM foo
ORDER BY OrderDate DESC
) a
ORDER BY OrderDate ASC
) b
ORDER BY OrderDate DESC