---

Hey

Jeg har har en relativ stor bruger tabel ca. 5000 (A). Alle brugere er har
en række egenskaber. Det er strikket sådan sammen at disse egenskaber skulle
kunne tilføjes dynamisk. Så istedet for at ligge dem som fields er der lavet
en tabel som så kan indeholde disse egenskaber (B). En tredje tabel (C)
indeholder yderligere "options". Fx har man en egenskab , region, kunne
options indeholde jylland, sjælland og fyn.

(C) mapper en række B -> A og rækken har evt. en nullable C ref.

Ok. Det virker også glimrende men det er sindsygt langsomt. En query kan
tage op til et minut. Jeg kører MSSQL 2000 og er nu ved at overveje om jeg
kan forbre performance via indexere.

Men jeg har ingen ide om hvad der vil give "performance". Alle id´er er
natuligvis pk (giver det index funktionalitet automatisk? Det ligner det i
enterprise manager [pk index]). søgningen består 100 af joins og kriterier
på id´er så kan jeg optimere?

Har prøvet at lave clusterd index på tabellernes id´er, men ud over at rykke
rundt på rækkerne har det ikke gjort noget. Indsættelse hastighed betyder
INTET. Det er søgning der skal være hurtigt.

Ser frem til at høre fra jer
Anders

---

"Anders K. Jacobsen" wrote
>
> Jeg har har en relativ stor bruger tabel ca. 5000 (A). Alle brugere er har
> en række egenskaber. Det er strikket sådan sammen at disse egenskaber
> skulle kunne tilføjes dynamisk. Så istedet for at ligge dem som fields er
> der lavet en tabel som så kan indeholde disse egenskaber (B). En tredje
> tabel (C) indeholder yderligere "options". Fx har man en egenskab ,
> region, kunne options indeholde jylland, sjælland og fyn.
>
Kan du evt skitsere tabellerene?

> Men jeg har ingen ide om hvad der vil give "performance". Alle id´er er
> natuligvis pk (giver det index funktionalitet automatisk? Det ligner det i
> enterprise manager [pk index]). søgningen består 100 af joins og kriterier
> på id´er så kan jeg optimere?
>
100 joins er en del
Har du kikket på subselects?

> Har prøvet at lave clusterd index på tabellernes id´er, men ud over at
> rykke rundt på rækkerne har det ikke gjort noget.

Clustered index laver man aldrig på PK
Kik på om det kan betale sig på dine foreign keys

Clustered indexes laver man typisk på data hvor der mange gentagelser aldrig
unikke data eller næsten unikke

- Peter