[Robert]

Har en sida där jag tänkte begränsa antalet sökträffar om de blir för många, och därför be användaren att begränsa sin sökning (ja ni fattar...).

Grejjen är väl den att man gör detta främst av performance skäl, eller hur? Så då undrar jag; för att få reda på att det har returnerats för många träffar så måste ju ändå sql frågan ställas, så vad vinner man egentligen på det hela? Man tvingar faktiskt användaren att ställa *ytterligare* en sql fråga, dock lite mer optimerad, men ändå?
Det är ju inte heller så bra att först göra en count för då får du ju i snitt ännu sämre prestanda (först en count sats, sedan den "riktiga" slq frågan).

Är jag ute och cyklar? :blink:

[kullervo]

I vanliga fall när du gör en COUNT() så går det riktigt fort i och med att du förmodligen har vettiga indexeringar. Om du t.ex kör en COUNT() utan WHERE-argument så spelar det ingen roll om det ligger 5 eller 8.000.000 poster i tabellen eftersom den läser direkt från primary-key-indexet. Men det är klart, det är säkert möjligt att en COUNT() är seg om det är avancerade WHERE-argument. Det du kan göra då om du vill få ut de 100 första är att du sätter LIMIT på 101. När du stegat igenom de 100 första kan du kontrollera om det finns en till.

[Robert]

Grejjen är den att jag inte vill visa de första xxx resultaten om antalet träffar blev mer än xxx. Jag vill inte visa någonting! Kanske låter icke användarvänligt men det finns andra anledningar till varför jag gör på detta sätt.

Alltså en LIMIT eller TOP har jag ingen direkt användning av.

Uhm, WHERE argument använder jag därför att det är just en sökning, så det blir maximalt 4st LIKE '%xxxxx%' argument + i vissa fall av avancerad sökning även lite JOINS. Så ja, det tar en stund att köra COUNT först... =/

[kullervo]

Originally posted by Robert@Jul 7 2004, 09:30
Grejjen är den att jag inte vill visa de första xxx resultaten om antalet träffar blev mer än xxx. Jag vill inte visa någonting! Kanske låter icke användarvänligt men det finns andra anledningar till varför jag gör på detta sätt.

Alltså en LIMIT eller TOP har jag ingen direkt användning av.

Uhm, WHERE argument använder jag därför att det är just en sökning, så det blir maximalt 4st LIKE '%xxxxx%' argument + i vissa fall av avancerad sökning även lite JOINS. Så ja, det tar en stund att köra COUNT först... =/

Oj då. Glömde att du inte skulle visa nånting om det blev för många resultat. Men du behöver ju inte stega igenom alla resultaten för att ta reda på hur många det är. I det programmeringsspråk du använder finns det säkert färdig funktion för att se hur många poster du fick i en ställd SQL-fråga.

Så du har benchmark:at tiden det tar att utföra normala COUNT() på olika sökningar och sett att det är segt?

Jag skulle gissa på att det här blir snabbast. Utgår från att det är max 100 st. resultat som ska visas.
1. Gör själva sökningen med LIMIT 101
2. Kontrollera hur många svar du fick.
3. Om det är färre än 101 svar, skriv ut dem. Annars skriv ut felmeddelande.


Det finns bara ett sätt att ta reda på vad som verkligen är effektivast och det är att testa. Slumpa ut 1000 frågor och kör dom på de två olika sätten. Jag kan i alla fall inte komma på något annat revolutionerande smart sätt att göra det på.

[zoran]

Originally posted by Robert@Jul 6 2004, 23:32
Har en sida där jag tänkte begränsa antalet sökträffar om de blir för många, och därför be användaren att begränsa sin sökning (ja ni fattar...).

Grejjen är väl den att man gör detta främst av performance skäl, eller hur? Så då undrar jag; för att få reda på att det har returnerats för många träffar så måste ju ändå sql frågan ställas, så vad vinner man egentligen på det hela? Man tvingar faktiskt användaren att ställa *ytterligare* en sql fråga, dock lite mer optimerad, men ändå?
Det är ju inte heller så bra att först göra en count för då får du ju i snitt ännu sämre prestanda (först en count sats, sedan den "riktiga" slq frågan).

Är jag ute och cyklar? :blink:

Varför vill du "tvinga användaren" att skriva bättre söksträng? Det är inte direkt användarvänligt.

I självaste verket kan du "begränsa" din query för varje sida:

exempel:

Du har 1 000 sidor med innehållet test i kolumnen "data".

Så du gör mer eller mindre:

$max_hits_page = 100; //Antal träffar per sida
$page = $_GET['page']; //Nuvarande sida, sidan fås genom GET-request
$start = (( $page -1 ) * $max_hits_page); //Vilken rad vill jag starta med ? Ifall det är sida 2 och vi har 100/page så blir resultatet 100 (det är ju där vi vill starta)
select * from data_table where data like '%test%' limit $start,$max_hits_page;

Då får du en query som inte returnerar mer än 100 rader.

Hur du sen räknar fram hur många sidor du har fått och hur du ritar upp [1][2] .. osv länkar lämnas åt dig som en övning

/Zoran

[Robert]

Ursprungligen postat av zoran

Varför vill du "tvinga användaren" att skriva bättre söksträng? Det är inte direkt användarvänligt.

I självaste verket kan du "begränsa" din query för varje sida:

exempel:

Du har 1 000 sidor med innehållet test i kolumnen "data".

Så du gör mer eller mindre:

$max_hits_page = 100; //Antal träffar per sida
$page = $_GET['page']; //Nuvarande sida, sidan fås genom GET-request
$start = (( $page -1 ) * $max_hits_page); //Vilken rad vill jag starta med ? Ifall det är sida 2 och vi har 100/page så blir resultatet 100 (det är ju där vi vill starta)
select * from data_table where data like '%test%' limit $start,$max_hits_page;

Då får du en query som inte returnerar mer än 100 rader.

Hur du sen räknar fram hur många sidor du har fått och hur du ritar upp [1][2] .. osv länkar lämnas åt dig som en övning

/Zoran

zoran: Tvinga? Om användaren tex endast öker på bokstaven "a" så får den ju tusentals träffar. Jag ber då användaren att förfina sökningen. Det är väl normalt, knappast oanvändarvänligt, snarare tvärtom.

Sen är det givetvis inga problem med [1][2]... etc, jag gör detta manuellt öven fast jag skulle kunna få den funktionaliteten gratis i .Net

Kullervo: Javisst, det är inga problem att se hur många recordsets jag har fått, men då är ju "skadan" redan skedd: sql satsen har körts och alla rs har skickats till webservern (IIS6 i mitt fall). Då kan jag ju lika gärna visa alla resultat när jag ändå har dom tillgängliga.


Såsom jag ser det:
En count sats tar längre tid än en select, men det blir bara ett minimalt recordset att skicka tillbaka. Dock måste jag köra en count före varje sökning, dvs 2 sql satser (den andra bara om counten är under ett givet tal, ex 100st)

Frågan är vad man tjänar på?

[zoran]

Originally posted by Robert@Jul 7 2004, 12:23
zoran: Tvinga? Om användaren tex endast öker på bokstaven "a" så får den ju tusentals träffar. Jag ber då användaren att förfina sökningen. Det är väl normalt, knappast oanvändarvänligt, snarare tvärtom.

Sen är det givetvis inga problem med [1][2]... etc, jag gör detta manuellt öven fast jag skulle kunna få den funktionaliteten gratis i .Net

Kullervo: Javisst, det är inga problem att se hur många recordsets jag har fått, men då är ju "skadan" redan skedd: sql satsen har körts och alla rs har skickats till webservern (IIS6 i mitt fall). Då kan jag ju lika gärna visa alla resultat när jag ändå har dom tillgängliga.


Såsom jag ser det:
En count sats tar längre tid än en select, men det blir bara ett minimalt recordset att skicka tillbaka. Dock måste jag köra en count före varje sökning, dvs 2 sql satser (den andra bara om counten är under ett givet tal, ex 100st)

Frågan är vad man tjänar på?

Nja, jag vet inte riktigt om jag håller med dig. Jag tycker att en BRA sökmotor låter användaren bestämma vad den vill söka efter. Visst, du kanske kan ta bort möjligheten att söka efter 1-teckensträngar men resten ska gå.

En annan sak, även om du skickar hela recordsettet till webbservern är inte jobbet klart. Den stora biten återstår. RS ska bearbetas och sättas i snygga div-ar eller tabeller och skickas till användarens browser. Det tar betydligt längre tid. Speciellt om du har databasservern på samma maskin som din webbserver.

/Z

[Robert]

Ursprungligen postat av zoran

Nja, jag vet inte riktigt om jag håller med dig. Jag tycker att en BRA sökmotor låter användaren bestämma vad den vill söka efter. Visst, du kanske kan ta bort möjligheten att söka efter 1-teckensträngar men resten ska gå.

En annan sak, även om du skickar hela recordsettet till webbservern är inte jobbet klart. Den stora biten återstår. RS ska bearbetas och sättas i snygga div-ar eller tabeller och skickas till användarens browser. Det tar betydligt längre tid. Speciellt om du har databasservern på samma maskin som din webbserver.

/Z

Jag visar bara 10 träffar åt gången så det blir inget extra arbete om det är 20 eller 50 träffar.

Och sen pratar jag om en sökfunktion som jag har på en site, inte en sökmotor i allmän mening. Jag tror iaf att det är "service" åt användaren att bespara honom 1000 träffar och istället upplysa honom om att han måste rafinera sin sökning lite. Risken är annars att det svar han tycker är relevant kan hamna långt ner i träfflistan. =)

[zoran]

Originally posted by Robert@Jul 7 2004, 15:24
Jag visar bara 10 träffar åt gången så det blir inget extra arbete om det är 20 eller 50 träffar.

Och sen pratar jag om en sökfunktion som jag har på en site, inte en sökmotor i allmän mening. Jag tror iaf att det är "service" åt användaren att bespara honom 1000 träffar och istället upplysa honom om att han måste rafinera sin sökning lite. Risken är annars att det svar han tycker är relevant kan hamna långt ner i träfflistan. =)

Service är att _tala om_ att han _bör_ rafinera en sökning. Inte att beordra. Ifall du genererar fler än 1000 träffar bör ju användaren kunna se det och naturligtvis själv komma på att rafinera sökningen.

Nåja, det här är bara min personliga åsikt. Om man nu skulle få för sig någongång att söka på "ta" så vill man få alla relevanta träffar, inte att systemet snålar med resurser och tvingar mig rafinera min sökning. Föreslår, ja, men inte tvingar.

Detta är bara min åsikt. Du delar den uppenbarligen inte med mig. B)

/Z