---

Jeg har en tabel med

ID (fortløbende unik nøgle)
Kommune
Ejendom
Bygning

De tre sidste udgører tilsammen et index. ID'et benyttes udelukkende i
forbindelse med relationer.

Det andet index benyttes ved søgning.

Mit spørgsmål er nu: en tabel kan indeholde ét clustered index. Hvor
opnår jeg størst udnyttelse af et clustered index?

Alle felter er af typen integer.

mvh /Snedker
---

---

>Mit spørgsmål er nu: en tabel kan indeholde ét clustered index. Hvor
>opnår jeg størst udnyttelse af et clustered index?

Svar: På dit andet indeks.

Clustered indeksering er fysisk sortering af data på disken. Derfor
kan man i sagens natur kun have ét clustered indeks pr. tabel. Brug
det på det indeks, der anvendes hyppigst.

Hvis din PK ikke repræsenterer nogen værdi rent søgemæssigt, så er der
ingen grund til at bruge clustered indeksering på den. Det er typisk
situationen ved de fortløbende unikke nøgler.

Jeg har f.eks. en tabel hvor PK er sammensat af fem tekniske felter,
som brugeren ikke kender til. De har ingen søgemæssig værdi. Derimod
er tabellen clustered efter et datofelt, da alle søgninger sker på
baggrund af en afgrænset datoperiode.

/Jan

---

"Morten Snedker" wrote

> Mit spørgsmål er nu: en tabel kan indeholde ét clustered index. Hvor
> opnår jeg størst udnyttelse af et clustered index?
>
Det er ret enkelt at besvare
Et clustered index benyttes udelukkende hvor du har en større gruppe data af
samme værdi
Typisk er foreign keys gode kandidater

- Peter

---

On Wed, 25 May 2005 19:20:39 +0200, "Peter Lykkegaard"
<peter.aghl@gmail.com> wrote:


>> Mit spørgsmål er nu: en tabel kan indeholde ét clustered index. Hvor
>> opnår jeg størst udnyttelse af et clustered index?
>>
>Det er ret enkelt at besvare
>Et clustered index benyttes udelukkende hvor du har en større gruppe data af
>samme værdi
>Typisk er foreign keys gode kandidater

Så, som jeg opfatter dit og Jans indlæg:

Når man opretter en PK i en tabel på en MS-SQL 2000, så sættes denne
primære nøgle som standard til at være clustered - og det er
uhensigtsmæssigt..ik'?

OT:
har lige rodet med full-text indexing på 15.000+ word-dokumenter. Jeg
er absolut benovet over søgehastigheden! Havde bare trang til at
fortælle det...

mvh /Snedker
---

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Morten Snedker <morten.snedker@planprojekt.dk> writes:

> OT:
> har lige rodet med full-text indexing på 15.000+
> word-dokumenter. Jeg er absolut benovet over søgehastigheden! Havde
> bare trang til at fortælle det...

Det er heller ikke så underligt, at du får god performance på det. Det
er ret enkelt at lave et godt fritekstindeks, og hvis man er villig
til at gå en smule på kompromis med enkelheden (hvilket de fleste
producenter af DBMS'er jo ikke burde have problemer med), kan man få
rigtigt, rigtigt god performance ifht. mængden af data.

Jeg pønser lidt på at lave min egen mini-RDBMS, bare for sjov og den
erfaring, det vil give mig, og jeg ville meget hurtigt gå efter at få
lavet et fuldtekstindeks, implementeret som et komprimeret
bitmapindeks. Hvis du er interesseret i at vide mere om den slags, kan
du jo spørge Google om bitmatindekser, muligvis også GiST-træer.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkKWNesACgkQYu1fMmOQldVdcACg1p1oBp8GRmliVU/Ui2axCJWa
4VIAoItCQoykAUyNCCBZNR5giTFZ0wN1
=d7aN
-----END PGP SIGNATURE-----

---

Morten Snedker wrote:
>
> Så, som jeg opfatter dit og Jans indlæg:
>
> Når man opretter en PK i en tabel på en MS-SQL 2000, så sættes denne
> primære nøgle som standard til at være clustered - og det er
> uhensigtsmæssigt..ik'?
>
Meget
Og helt ubrugeligt imho

- Peter