Ytelse med millioner av rader [Løst]

[hpfarstad]

En tabell kalt Questions og en annen kalt Alternatives. Alternatives inneholder svaralternativer på et spørsmål i Questions, og har fremmednøkkel fra Questions.

 

Eksempel:

ID | Question | CorrectID

1 | Hva er hovedstaden i Norge? | 2

 

ID | SpørsmålsID | Alternativ

1 | 1 | Bergen

2 | 1 | Oslo

3 | 1 | Trondheim

 

La oss si det blir 5 millioner rader av spørsmål, og dermed mellom 10 og 30 millioner rader med svaralternativer.

 

Når MS SQL skal hente ut disse radene, blir det ikke forferdelig krevende?

 

Hadde det vært bedre å droppe Alternatives-tabellen og heller legge svaralternativene i en tokenseparert string?

Eksempel:

ID | Question | Alternatives | Answer

1 | Hva er hovedstaden i Norge? | Trondheim;Bergen | Oslo

 

... Selv om dette bryter med god normaliseringsskikk?

Endret 11. desember 2007 av hpfarstad

[BigJackW]

Det er her 'Joins' kommer inn.

 

Søk litt på google.

 

Om du har problemer med å forstå kan du se på disse illustrasjonene:

http://www.khankennels.com/blog/index.php/.../getting-joins/

 

Men, om det vil bli mindre ressurskrevende å ha 1 tabell i stede for 2 vet jeg ikke.

[hpfarstad]

Det er her 'Joins' kommer inn.

 

Søk litt på google.

 

Om du har problemer med å forstå kan du se på disse illustrasjonene:

http://www.khankennels.com/blog/index.php/.../getting-joins/

 

Men, om det vil bli mindre ressurskrevende å ha 1 tabell i stede for 2 vet jeg ikke.

 

 

Joda, er kjent med JOIN. Tenkte mest på selve prosessen med å joine - hvor krevende blir det når man skal joine 3-4 rader ut i fra 20 millioner.

[roac]

Joda, er kjent med JOIN. Tenkte mest på selve prosessen med å joine - hvor krevende blir det når man skal joine 3-4 rader ut i fra 20 millioner.

Det er her inideksering kommer inn Med fornuftig indeksering så er det intet problem

[kaffenils]

Som roac sier så er index det magiske ordet.

 

En clustered primary key (clustered er default for primary keys) på SpørsmålsId og Id på tabell Alternatives så vil SQL Server kun behøve 3-4 reads for å finne alle alternativene for et gitt spørsmål. Uansett om du har tusen eller hundre millioner spørsmål. Ok, så blir det kanskje 4-5 reads hvis du kommer opp i hundremillionersnivået

[hpfarstad]

Som roac sier så er index det magiske ordet.

 

En clustered primary key (clustered er default for primary keys) på SpørsmålsId og Id på tabell Alternatives så vil SQL Server kun behøve 3-4 reads for å finne alle alternativene for et gitt spørsmål. Uansett om du har tusen eller hundre millioner spørsmål. Ok, så blir det kanskje 4-5 reads hvis du kommer opp i hundremillionersnivået

 

 

Genialt! Takker for svar!