Nogen der kan forklare mig om denne form for paging er god eller dårlig om man vil?
Jeg spørger fordi jeg synes den er langsom og belaster min MySql / PC meget ved paging, der er godt 1 mill. poster i databasen, men det burde vel ikke være et problem?
*Jeg har tilføjet diverse tabeller til index.
<% pageSize = 10 currentPage = 0 if isnumeric(Request.querystring("Page")&"") then currentPage = cInt(Request.querystring("Page"))
Set rs = Conn.Execute("SELECT * FROM data WHERE bruger = '"&replace(session("bruger"), "'", "''")&"' ORDER BY ID DESC LIMIT "& currentPage &","& pageSize &"") %>
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Jo, id er nøgle og der er index på bruger. Men dette script gemmenløber/counter alle 1 mill. poster hver gang siden hentes, kan det ikke gøres mere skånsomt og mindre belastende?
punnishment > Jep! Generelt mener jeg, at man kun skal spørge efter det man skal bruge og desuden lade databasen foretage så meget databehandling som muligt (frem for ASP, PHP etc.).
<% if currentPage > 0 then %> <a href="side.asp?page=<%= currentPage-pageSize %>">næste</a> <% end if set rs = conn.execute("select count(*) from data WHERE bruger = '"&replace(session("bruger"), "'", "''")&"'") if not rs.eof then if isnumeric(rs(0)&"") then if rs(0) > currentPage+pageSize then %> <a href="side.asp?page=<%= currentPage+pageSize %>">forrige</a> <% end if end if end if %>
jeg siger bare at LIMIT n,m formentligt er så optimeret som det kan blive performance mæssigt
og at problemet er i konsistens af resultater
det vil ikke gennemløbe alle rækker hvis der er index på det du tester på i WHERE
så din kode i spørgsmålet ser fornuftigt ud performance mæssigt
jeg ved ikke helt med din count, måske skulle du hente m+1 og ikke vise den sidste men bruge eksistensen af den til at beslutte dig for om der er en next page
hvor sløv er den her? Dette er blot et simpelt eksempel, hvor jeg har en tabel med bruger oplysninger, også en tabel med bil oplysninger på de biler en bruger eksempelvis ejer. I nogle af mine løsninger er data-opdelingen så stor, at jeg tit skal have fat i 3-4 tabeller for at få et simpelt udtræk. Pladsmæssigt i databasen er dette jo den mest optimale måde, men hvordan hænger det sammen med perfomance?
SQL = "SELECT bil.navn, bil.pris, bil.kobt, users.username FROM users, bil WHERE users.id = bil.userid"
yes det er der! Der er mange der benytter metoder som INNER JOIN, INNER LEFT/RIGHT osv., og det de funktiner stortset gør, er at sammensmelte to tabeller til en "fiktiv" tabel, som du kan trække oplysninger udfra. Det er jo ligepræcis det jeg gør ved ovenstående metode, men hvad er at fortrække? At bruge JOIN eller den metode jeg bruger (ved ikke lige hvad den hedder) ?
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
