Det är öppet för SQL-injektion, stoppa aldrig in användardata direkt på det där sättet. Byt ut Request.QueryString("id") mot något i stil med CInt(Request.QueryString("id"))
Läs gärna mer om sql-injection och om hur du kan skydda dig på swesecures hemsida i artikeln SQL Injection.
Angående din fråga så är det helt beroende av hur många anrop du har till din sida samt hur många poster du har i ditt recordset. Generellt sett är det snabbare att loopa en array. Men om det märks i ditt fall går inte att säga.
Det viktigaste istället - om du har prestandaproblem - är att indexera din databas på ett korrekt sätt, samt att använda cache. Läs gärna swesecures artikel om index.
Det med sql-injections vet jag. Ska läggas in men undrar om man använder getrowskoden som är ovan.. den har ej recset.close: set recset=nothing.. Det ska väl vara med eller?
Jag skulle nog inte rekommendera att använda .GetRows alls faktiskt. Det finns ett antal anledningar;
1. Du går helt miste om kolumnernas benämningar/namn. Koden blir således mycket svårläst (för att inte säga oläslig).
2. Den prestandaskillnad som det ger är relativt marginell. Det är liksom inte längre värt det, då det finns mycket, mycket annat som bör optimeras innan man ger sig på att optimera saker som listning av data.
3. Ändrar du databasens kolumnordning/kolumnantal etc, är risken till 90% att du kommer få problem i koden, då index'en i din datamatris antagligen påverkas av detta. Ett recordset håller namn till skillnad från din GetRows-metod som bara har index i kolumnordning.
Dessutom; jag ser att du använder index för att referera till kolumner i ditt Recordset. Det finns ingen som helst mening med detta, så sluta med det omedelbart. ;) Där är ungefär som att döpa sina applikationsfiler till 001.asp, 002.asp, 003.asp osv.
Dessutom; jag ser att du använder index för att referera till kolumner i ditt Recordset.
Njaa... :) För absolut bästa prestanda så hämtas data ut snabbare med index än med kolumn-namnet. Dock så blir läsbarheten som sagt sämre....
...att använda GetRows() ger visserligen mer svårläst kod, men den behöver inte blir svårare att underhålla beroende på hur man bygger sin logik...i en skiktad lösning där enititets-klasser används, så blir det ändå bara ett ställa att ändra på...men då är det ändå inte prestanda-optimerat, så det går kanske på jämt ut då :)
Dessutom; jag ser att du använder index för att referera till kolumner i ditt Recordset.
Njaa... :) För absolut bästa prestanda så hämtas data ut snabbare med index än med kolumn-namnet. Dock så blir läsbarheten som sagt sämre....
Dock; jag tror det finns andra delar som kan optimeras lättare/mer effektivt än just sådana saker i en applikation som denna. Det känns som att jaga myror med hagelgevär, speciellt när man tummar så mycket på läsbarheten i koden och spikar sin databasstruktur så hårt som i detta fallet. Det är liksom inte på grund av att Asa refererar sina kolumnnamn med strängar istället för index som hennes applikation kommer få prestandaproblem, om det nu inträffar. Och om det nu är så att man måste göra sådana optimeringar, då är det nog dags att se sig om efter ny hårdvara/hosting.
fredrik skrev:
...att använda GetRows() ger visserligen mer svårläst kod, men den behöver inte blir svårare att underhålla beroende på hur man bygger sin logik...i en skiktad lösning där enititets-klasser används, så blir det ändå bara ett ställa att ändra på...men då är det ändå inte prestanda-optimerat, så det går kanske på jämt ut då :)
Man får ju återigen se på vilket context vi ligger inom i det här fallet också. Jag tvivlar på att Asa's applikation följer någon slags N-tiermodell, än mindre använder/är uppbyggt med klasser eller objekt i så stor utsträckning.
Du använder GetRows, vilket är ett bekvämt sätt att förminska läsbarheten av koden på. Det lilla du vinner i prestanda på det är förmodligen inte värt det.
Jomenvisst, här tycker vi lika för en gångs skull ;)
Sen kan man påpeka att datum borde lagras som datum i en kolumn i stället för som heltal i tre kolumner, men det är en annan sak...
Nja, en datumkolumn (iallafall i t.ex. SQL-server) ser ju till att hålla reda på inte bara datum, utan även kalenderdatum, vilket innebär att du t.ex. inte kan föra in datumet 2004-02-31. Har du det uppdelat i tre kolumner som bara fattar heltal så kan ju ju i princip få in datum som 2005-40-67, och den månaden finns ju inte på vår planet, så.. ;)
Dessutom slipper du hålla på att formatera datumet varje gång du skall använda det. Vidare; det brukar anses som en dödssynd att stränghantera datum på det sättet. :OO
Jag kan liksom inte se någon riktig fördel med det.
357 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2