Forskellen mellem et klynget og ikke-klynget indeks er, at det klyngede indeks bestemmer den fysiske rækkefølge af rækkerne i databasen . Med andre ord, at anvende det klyngede indeks på PersonId betyder, at rækkerne bliver fysisk sorteret efter PersonId i tabellen, hvilket gør det muligt for en indekssøgning på dette at gå direkte til rækken (i stedet for et ikke-klynget indeks, som ville lede dig til rækkens placering og tilføje et ekstra trin).
Når det er sagt, er det usædvanligt for den primære nøgle ikke at være det klyngede indeks, men ikke uhørt. Problemet med dit scenarie er faktisk det modsatte af, hvad du antager:du vil have unik værdier i et klynget indeks, ikke dubletter. Fordi det klyngede indeks bestemmer den fysiske rækkefølge af rækken, hvis indekset er på en ikke-unik kolonne, så skal serveren tilføje en baggrundsværdi til rækker, der har en dubletnøgleværdi (i dit tilfælde alle rækker med samme PersonId ), så den kombinerede værdi (nøgle + baggrundsværdi) er unik.
Det eneste, jeg vil foreslå, er ikke ved hjælp af en surrogatnøgle (dit CourtOrderId ) kolonne som den primære nøgle, men brug i stedet en sammensat primær nøgle af PersonId og en anden unikt identificerende kolonne eller sæt af kolonner. Hvis det dog ikke er muligt (eller ikke praktisk), så sæt det klyngede indeks på CourtOrderId .