hur snabb blir sidan?

Hämtar du ur en databas så kan du ju dela upp informationen automatiskt med ASP. Eller vad är det du kör?

------------------
-Nicke-
nSoft.nu

Men om man gor pa detta sattet maste ju sidan bli jattelangsam om man har manga anvanare och manga tavlingar.

Söktiden i databasen ökar inte linjärt med antalet poster. Har man bra index (vilket diskuterades i en tråd rätt nyligen) och databashanteraren har någorlunda vettiga sökalgoritmer kan antalet "hopp" man gör bli väldigt litet.
Använder man s.k. binärsökning (vilket jag antar att databashanterare gör, annat vore konstigt) kan man hitta en enskild post med kanske tjugo jämförelser i en tabell med en miljon rader (d.v.s. 50000 gånger färre jämförelser än poster).
Man måste iofs ha ett sorterat index över posterna, vilket gör insättning något långsammare, men det är oftast inte särskilt mycket och man vinner mycket på det när man ska plocka fram data.

------------------
You can be a coward for a few minutes, or dead forever. /Rincewind

[Redigerat av spango den 08 dec 2001]

Jag har bara ID-kolumnen (räknare) som index i mina databaser och kan knappast indexera fler kolumner.

Hur mycket snabbare blir sökningen med en ID-kolumn och hur mycket tjänar man ytterligare på att indexera fler kolumner.

Abstrakt fråga, jag vet...

Tack for hjalpen...
Spango, du skriver "Man måste iofs ha ett sorterat index över posterna, vilket gör insättning något långsammare". Hur gor man detta?

Tack! /Erik

Jag har bara ID-kolumnen (räknare) som index i mina databaser och kan knappast indexera fler kolumner.

Det går hur bra som helst att indexera alla kolumner man kan komma att tänka på. Det är inte primärnycklar vi pratar om, alltså...

Hur mycket snabbare blir sökningen med en ID-kolumn och hur mycket tjänar man ytterligare på att indexera fler kolumner.
Det är vilka kolumner som användarna söker på oftast som avgör om man ska indexera. Hur mycket snabbare det går är svårt att säga, det beror på algoritmen (och säkerligen en hel del annat). Med binärsökning ökar den procentuella vinsten med antalet rader man söker på, man behöver 4-5 gissningar för att få fram en rad bland 20 andra, men bara 20-30 gissningar bland en miljon andra poster.
Man kan säga att den egenskapen är definitionen för bra sökalgoritmer.

Hur gor man detta?
Det beror på vilken DBMS du har. Jag skulle gissa att de flesta automagiskt indexerar primärnycklarna, för det vore otroligt korkat att inte göra det :) (Ett argument som stöder min tes är att tabeller i såväl MySQL som Access tycks bli sorterade efter primärnyckeln.)
I Access finns det en knapp som har heter index (den har en liten blixt på sig). I MySQL säger du något i stil med CREATE INDEX indexets_namn ON tabellens_namn(kolumnen_som_ska_indexeras) och jag skulle gissa att det ser likadant ut i andra DBMS:er där man sköter saker & ting via SQL-kommandon.
När du väl skapat indexet tar DBMS:en hand om det, så du behöver inte bekymra dig mer om den saken. Bara luta dig tillbaka och njut av hastigheten :)

------------------
You can be a coward for a few minutes, or dead forever. /Rincewind

[Redigerat av spango den 08 dec 2001]

spango, dina accesskunskaper ligger nog pa en niva over mina. Min tabell ser ungefar ut sa har: ResultatID (primarnyckel), SpelarID, Tavling, Resultat. ResultatID har jag en raknare pa, mest for att fa ett specifikt (unikt) varde pa vaje resultatinmatning (jag anvander nastan aldrig denna kolumn). SpelarID har en relation med en annan tabell (dar info om spelaren finns). Tavling visar vilken tavling resultatet hor ihop med, och denna kolumn ar relaterad till en annan tabell (med info om tavlingen). Resultat visar vilket resulat spelaren hade. For att fa fram resultat fran en specifik spelare vid en specifik tavling, skriver jag typ : SQL="SELECT Resultat FROM Resultat WHERE SpelarID = 'spelaren man har valt' AND Tavling = 'tavlingen man har valt"

Skulle detta sattet bli langsamt (t.ex. om man ville hamta resultat for en spelare i dess samliga tavlingar). Jag hittade knappen med blixten pa (som du sa) men jag fattade inte riktigt vad jag skulle gora med den.

Hur ska jag gora om min databas?
Tack! /Erik

Om jag inte fått det här med indexering helt om bakfoten så går det väl inte att indexera om det kan tänkas dyka upp samma värden i samma kolumn flera gånger. Stämmer detta eller?

Nej, det stämmer inte. Ett index kan innehålla duplikat. En primärnyckel, däremot, får inte innehålla duplikat. Man kan också definera att andra kolumner är unika antingen genom att skapa ett uniqueconstraint eller ett unikt index

 create table ogrish(aleb char(12) primary key, bleb varchar(6) unique)

 create unique index iii on t(a,b)

------------------
essentitia preter non sans multiplicandum

for att uttrycka mig tydligt..
vad ar indexering och hur gor man det? Vad ar det bra for?

Tack!

Ett index används för att snabba upp sökningar i en databas.

Säg att du har en tabell med personuppgifter

personnummer!förnamn!efternamn!övrigt
------------------------------
1906147801!Karin!Nilsson
2503129339!Roland!Ögren
5005121065!Britta!Johansson
5306097536!Anders!Svensson

personnummmer är primärnyckel och kan bara innehålla unika värden. Primärnyckelskolumner blir oftast indexerade automatiskt.

De flesta sökningar kommer förmodligen ske på för och efternamn. För att hitta ett namn så måste man söka igenom alla poster då namnen inte ligger i någon speciell ordning. Om man har 100 poster så är det inte så kostsamt men söktiden växer linjärt med antalet poster.

För att minska söktiden så kan man skapa ett index på för och efternamn. Databashanteraren kommer då att lägga till en extra tabell som är sorterad efter innehållet i dessa kolumner

efternamn!förnamn!referens
------------------------------
Johansson!Britta
Nilsson!Karin!
Svensson!Anders
Ögren!Roland

i indexet finns också en referens till den ursprungliga tabellen så att man enkelt kan hitta den posten. I och med att data ligger sorterat så kan man söka rätt på data mycket snabbare. Exakt hur sökningen går till och hur referensen till tabellen ser ut skiljer sig mellan olika databashanterare.

Ett index innebär en ökad kostnad för update/insert/delete operationer då man ändrar både i tabellen och i indexet.

Korrekta index är det viktigaste för att få bra prestanda i en databas, speciellt om man joinar tabeller.

Om man har tre tabeller med vardera 1000 rader och gör en join mellan dessa utan att det finns några index så innebär det att man måste läsa 1000*1000*1000 = 1 miljard poster.

Jag har sett exempel där man genom att lägga till ett index fått ner söktider från 12 timmar till 1 sekund.

Du kan använda sql för att skapa index

create index index_name on table_name(column_name1,column_name2)

Olika databashanterare kan ha lite olika tillägg som man kan ange.

Hur man skapar ett index via Access eller något annat administrationsverktyg har jag inte en aning om.

------------------
essentitia preter non sans multiplicandum

Klantiga jag har inte sett att det finns ett ytterligare alternativ för indexering i access förrän nu. Förutom "nej" och "ja - inga dubbletter" finns det ju även "ja - dubbletter tillåtna".

Räcker det med att ändra denna inställning i access för att snabba upp sökningen eller måste man använda scripten, som LarsG nämnde?

De kryssboxar i Access som du nämner är alternativ till den sql-sats som jag skrev, så du behöver inte båda.

------------------
essentitia preter non sans multiplicandum

Tack sa mycket LarsG, nu ar jag nara (din forklaring om Index var utmarkt). Om jag klickar pa Indexblixten kommer en ruta upp dar jag kan skriva in hur indexen ska se ut. Nar jag stanger denna rutan, fragar den emellertid inte om jag vill spara, och jag ser inga andringar pa skarmen. Har jag gjort ratt? Rekomenderar du att jag ska ge indexet samma namn som faltnamnet, eller ska jag kalla den typ faltnamn_index?

Tack! /Erik

Nu vet jag inte hur det fungerar i Access så jag kan inte svara på om du har gjort rätt eller inte.

Hur du namnger indexet har jag heller ingen direkt åsikt om. Det viktiga är att du är konsekvent i din namngivning.

------------------
essentitia preter non sans multiplicandum