Indexering

Jag skulle behöva lite hjälp/tips om indexering.
Jag har bara använt väldigt simpla databaslösningar i Access tidigare men nu ska jag köra i MSDE.

Databasen kommer mest att användas för att söka efter bilder. Bilderna kommer ha flera attribut kopplade till sig. Det vanligaste scenariot är att en användare väljer några sökparametrar som t.ex. sökord och kategori och sedan väljer den bild de vill se mer information om.

Jag har gjort lite sökningar för att få rätsida på indexeringsbiten men jag tycker det ofta är ganska "luddigt" och svaren går ibland även emot varann.

Till frågorna...

1. Ska man alltid använda indexering? Min databas kommer i startläget antagligen att ha som mest 500 poster i en tabell. Jag tror inte att det kommer vara mer än 100 000 - 200 000 poster inom en snar framtid.

2. Behöver/ska man indexera fält som är primärnyckel. I nästan alla tabeller är det fält som t.ex. userID som är primärnyckel (int/identity).

3. Vad jag har förstått fungerar inte indexering om man har en fråga som t.ex. "SELECT col1, col2, col3 FROM t1 WHERE col3 LIKE '%xxxxx%'". Stämmer det? I så fall, kan man lösa det på annat sätt?

4. När ska man använda clustered och non-clustered indexes?

5. Ska man inte indexera fält som har många liknande värden?
   Jag kommer att ha flera fält (nVarChar) där värdena skulle kunna vara t.ex. "aaa;bbb;ccc;ddd;eee;fff;", "aaa;ccc;fff;ggg;hhh;" och "aaa;ddd;mmm;kkk;qqq;". (Det är på sådana fält som vissa av LIKE-sökningarna kommer genomföras).

6. Är det de fält som oftast förekommer i SQL-frågor man ska indexera?

7. Kan indexering göra att man snabbt når 2 GB-gränsen i MSDE för en normalstor databas?

När jag ändå är i farten... spelar det någon större roll om man definerar en nVarChar() som 1000 eller 4000 ur prestandaaspekt?

Tacksam för hjälp.
:e

1. Om tabellen bara innehåller så mycket data att det ryms på en fysisk sida i databasen så finns det ingen anledning att indexera. Det beror även på hur många distinkta värden det finns. Om du har 500 poster i en tabell så lönar det sig nog att indexera de kolumner som du använder i sökningar.

2. Nej, primärnycklar blir automatiskt indexerade.

3. Ja det stämmer. Använd fulltext index om du vill söka i kolumner med datatypen TEXT.

4. Om man har många sökningar på ett intervall kan det löna sig att ha ett klustrat index på den kolumnen.

Jag kommer att ha flera fält (nVarChar) där värdena skulle kunna vara t.ex. "aaa;bbb;ccc;ddd;eee;fff;"

Nej, det skall du inte ha. Lagra varje enskilt värde som en post. Då behöver du inte använda like.

Nja, de kolumner som du ställer villkor på och de som förekommer i order by.

Ja.

Nej.

LarsG skrev:

1. Om tabellen bara innehåller så mycket data att det ryms på en fysisk sida i databasen så finns det ingen anledning att indexera. Det beror även på hur många distinkta värden det finns. Om du har 500 poster i en tabell så lönar det sig nog att indexera de kolumner som du använder i sökningar.

Hur/var ser jag hur mycket data som rymms på en fysisk sida i databasen?
Jag är total rookie när det gäller MSDE/SQL Server...

LarsG skrev:

3. Ja det stämmer. Använd fulltext index om du vill söka i kolumner med datatypen TEXT.

Jag har för mig att Text och nText lagras på annat sätt än nVarChar och att detta resulterar i sämre prestanda. Stämmer det?

LarsG skrev:

4. Om man har många sökningar på ett intervall kan det löna sig att ha ett klustrat index på den kolumnen.

Kan du utveckla vad du menar med "sökningar på ett intervall"?
:)

5. Jag kommer att ha flera fält (nVarChar) där värdena skulle kunna vara t.ex. "aaa;bbb;ccc;ddd;eee;fff;"

LarsG skrev:

Nej, det skall du inte ha. Lagra varje enskilt värde som en post. Då behöver du inte använda like.

Jag är med på vad du menar men jag kanske borde utveckla mer vad jag menar.
Texten "aaa;bbb;ccc;ddd;eee;fff;" (skulle för tydlighetens skull kunna vara "sol;bad;vatten;sommar;") representerar t.ex. sökord som en bild har kopplade till sig. Eftersom jag inte vill begränsa antalet sökord tänkte (trodde) jag att lösningen var att bunta ihop dem i ett fält.
Om jag har en post för varje sökord, blir det inte då en massa annan redundant data? Eller menar du att jag ska skapa en tabell med bara bildens id och sökord och i den ösa på med en post för varje sökord?

t.ex.

TABELL
bildID | sökord
1 | sol
1 | bad
1 | sommar
2 | whatever

LarsG skrev:

7. Ja.

Kan man ta bort indexeringar om man märker att databasen börjar gå upp mot 2GB för att få ner den i storlek?
Om man säger att det inte finns fler än 10 000 poster i någon tabell och man hoppar över indexering helt kan sökningarna ta flera sekunder då (om man räknar standardutrustning och uppkoppling)?

Det där att börja prata om sidstorlek var nog lite överkurs. Så noga behöver man inte vara. Andemeningen är att för små tabeller (t.ex. 20 rader om vardera 50 bytes) lönar det sig inte att indexera.

Jag har för mig att Text och nText lagras på annat sätt än nVarChar och att detta resulterar i sämre prestanda. Stämmer det?

Ja, oftast så lagrar man en referens till värdet i nText/Text kolumner vilket innebär att man måste göra en extra läsning för att hämta det faktiska värdet. SQL server har en ganska dålig implementation av stora objekt då de lagras i väldigt många små bitar.

Med sökningar på ett intervall menar jag att du har en fråga som ser ut som t.ex.

select * from t
where c1 between 100 and 200

om det då finns ett klustrat index på c1 så kan man utnyttja att dessa poster ligger nära varandra sidmässigt.

Eller menar du att jag ska skapa en tabell med bara bildens id och sökord och i den ösa på med en post för varje sökord?

Ja.

Kan man ta bort indexeringar om man märker att databasen börjar gå upp mot 2GB för att få ner den i storlek?

Jo, du kan ju undersöka vilka index som används. Det finns olika verktyg för SQL server som kan analysera huruvida befintliga index är behjälpliga och även föreslå andra index som skulle kunna hjälpa upp svarstiden. Vet ej om dessa finns tillgängliga för MSDE (förmodligen inte).

Om du saknar index kan frågor ta mycket längre tid än några sekunder. T.ex. om du joinar 3-4 tabeller med vardera 1000 rader så kan det resultera i genomläsning av en miljard poster om du inte har några index. Att ta bort index enbart för att minska på storleken är inte rätt väg.

Ja, oftast så lagrar man en referens till värdet i nText/Text kolumner vilket innebär att man måste göra en extra läsning för att hämta det faktiska värdet. SQL server har en ganska dålig implementation av stora objekt då de lagras i väldigt många små bitar.

Bör jag lägga den beskrivande texten (som man ska kunna söka på) som nText och göra fullTextindexering trots att jag har svårt att tro att någon post kommer innehålla mer än 500 tecken? Som standard skulle jag tro att de beskrivande texterna inte blir längre än 250 tecken.

Om du inte behöver kunna lagra unicode, så använd datatyper som inte börjar på n. n-typerna tar dubbelt så stor plats i lagringen.

@nders skrev:

Om du inte behöver kunna lagra unicode, så använd datatyper som inte börjar på n. n-typerna tar dubbelt så stor plats i lagringen.

Jag kommer behöva unicode inom en snar framtid så därför tyckte jag det var lika bra att lägga in det från början.