Sen så gillar jag inte i SPiNs kod att han inte stänger connection-objectet...
Snabbare hemsida
34 svar · 951 visningar · startad av danielpetersson · sida 2 av 2
Frågan, av danielpetersson
Hej! Jag håller på med en hemsida som är kopplade till en databas. Bla ska jag presentera en meny som är kopplade till databasen samt en sökfunktion. Det är en ganska stor databas. Jag skulle vilja att hemsidan blir snabbare än vad den är nu. Är där någon som har förslag på förändringar för att göra hemsidan snabbare? Tacksam för svar
Läs frågan i sin helhet →Jag initierade det å andra sidan inte heller, jag tyckte att det var underförstått. ;)
Ang. användningen av GetRows () och ändrar antalet fält: Du blir ändå tvungen att ändra din SQL-fråga, och har du byggt upp systemet på ett smart sätt så behövs det inte mer ändring i koden än om du arbetar med ett recordset.
Appropå ingenting så kan ni väl kolla på denna tråd och lägga lite energi på den kanske...
http://www.webforum.nu/showthread.php?s=&threadid=42564
Jag är i nöd!
//Jesper
arrMyArray = connect.Execute(sql).GetRows()
ger ett säkert felmeddelande om inte recordsetet returnerar några poster. För att hämta med .GetRows() måste recordsetet returnera minst en post så checken:
If Not objRS.EOF Then
behövs innan man hämtar med .GetRows()
Ang. användningen av GetRows () och ändrar antalet fält: Du blir ändå tvungen att ändra din SQL-fråga, och har du byggt upp systemet på ett smart sätt så behövs det inte mer ändring i koden än om du arbetar med ett recordset.
håller fullständigt med.
Vill man optimera så använder man .GetRows() så får man en klart mycket bättre prestanda.
En annan sak man kan göra för att optimera hämtningar från databasen är att ange .MaxRecords, dvs max antal poster som ska hämtas/returneras från databasen eller oxå någon annan typ av begränsning bör göras. Finns egentligen ingen mening med att hämta mer än ett par hundra poster åt gången.
kika in de olika sökmotorerna tex, de returnerar inte mer än 3 - 400 poster (20 sidor ungefär). Hittar man inte det man sökte krävs en mer definierad sökning (AND, NOT, OR etc)
cya,
PatrikB
Ursprungligen av SPiN Ang. användningen av GetRows () och ändrar antalet fält: Du blir ändå tvungen att ändra din SQL-fråga, och har du byggt upp systemet på ett smart sätt så behövs det inte mer ändring i koden än om du arbetar med ett recordset.
Inte om man använder SELECT *. Och gör man inte det så blir det ändå mer ändringar om man har GetRows eftersom att man måste ändra siffran på alla ställen man använder ett eller flera fält.
Om man arbetar med COM-objekt så är det inte alls säkert att det är en själv som gjort metoden som hämtar ut recordsettet. Och samma metod kan anropas från många sidor. Om då någon gör en ändring i databasen eller i SQLen så ska denna inte behöva rota igenom alla sidor för att leta/fixa till där man använt GetRows från den metoden eller behöva säga åt alla andra att fixa sina sidor.
Ursprungligen av Erik Juhlin Inte om man använder SELECT *. Och gör man inte det så blir det ändå mer ändringar om man har GetRows eftersom att man måste ändra siffran på alla ställen man använder ett eller flera fält.
Faktiskt inte. Om du skapar en bunt variabler efter hämtningen så behöver du bara ändra på ett ställe.
T.ex.
datDatum = 0
strNamn = 1
strEmail = 2
Sedan använder man bara arrExempel(datDatum,i).
Men man måste ändå gå in på varje sida och ändra de där siffrorna ju.
då kan man ju inte ha frånkopplade recordsets...
Exakt!!! det spara en hel del prestanda.
Recordset är bra när man behöver stega mellan poster, eller framförallt behöver postlåsning.
/T
Ska man vara riktigt kritisk i sitt tänkande så ska man anropa recordseten på samma sätt.
objRS(0) och ej med namnet objRS("ID") .... allt för prestandans skull *ler*
En annan sak, man ska ej heller ange SELECT * eftersom man oftast inte använder sig av alla fälten i tabellen och på det sättet får en overhead. Det man ska göra är att ange endast de fälten man ska använda, dvs SELECT Field1, Field2, Field3 FROM Table1
Om du senare vill ändra något i denna så måste du ändå gå in och ändra i recordseten oxå, antingen lägga till eller ta bort, på alla sidor som det används på.
cya,
PatrikB
Ursprungligen av Skarre
datDatum = 0
strNamn = 1
strEmail = 2
Rättelse: det ska naturligtvis vara "int" framför samtliga variabler. :r
PatrikB, gör man det så får man precis de nackdelarna man får med GetRows.
Sen om man vill göra generella Metoder så är SELECT * vettigt eftersom att man då inte vet vilka fält som kommer behövas. Och oftast behövs alla. Däremot om man har en massa joins så kan man hämta alla från "huvudtabellen" och utvalda fält från de injoinade tabellerna.
Att hålla på med en massa såna småoptimeringar vinner man inte så mycket på och man får sämre skalbarhet och koden blir otydligare.
Som någon sagt tidigare. Bryr man sig så mycket om prestanda så bör man nog överväga att byta språk. ;)
Man behöver oftast inte "alla" fält.
skulle vilja se den applikation som listar ut alla produkter med all information för att ta ett exempel. Oftast gör man listningar och visar endast minimalt med information och sedan om man vill ha mer information så "klickar" man sig vidare och ser all information.
Det med sämre skalbarhet för att man använder .GetRows istället för recordset har jag svårt att se ... utveckla gärna det lite mer ...
sedan håller jag med att vill man ha mer "prestanda" så sitter det oftast inte i om man använder recordset eller array utan mer om hur logiken i applikationen ser ut. Är den inte optimal så blir det en seg applikation. Är den optimal och applikationen ändå går segt det är då man behöver tänka på hur man mer kan optimera eller skaffa ny häftigare hårdvara .... eller tom byta språk som ett sista alternativ :e
cya,
PatrikB
PatrikB, då blir det ju olika metoder för att lista och hämta en. Tycker jag är väldigt onödigt och inte särskilt logiskt.
Tänker inte förklara mer om GetRows efter som att jag i ett tidigare inlägg i tråden tycker att jag förklarat det mycket bra.