Anvendelse og forvaltning af identitet kolonner i SQL Server

Når man designer en database til at understøtte anvendelser er væsentlig at overveje, hvordan man håndterer primære nøgler. Der er i denne forbindelse mindst to skoler til at tænke: en, der hævder, at det rigtige at gøre, er at bruge de såkaldte surrogat nøgler (dvs. ikke baseret på reelle data) og en anden, der hævder, der skal bruges i stedet for reelle data, som nøgleværdier. Så er der en mellemvej, som består i "en database til brug inden for begge disse løsninger, afhængigt af de relative fordele og ulemper (som vi snart).

Når du designer en tabel, er det som regel indeholder en eller flere kolonner, der udgør dens primære nøgle. Som vi kender en tabels primære nøgle er en værdi (eller en kombination af værdier), der entydigt identificerer hver række. Som tidligere nævnt, hvis en nøgle består af reelle værdier kaldes naturlige nøgle, men hvis for eksempel nøglen genereres, hver gang du indsætter en række i tabellen kaldes surrogat nøgle. En surrogat nøgle er normalt en numerisk værdi i SQL Server, og ofte de kolonner af denne type er dem af identitet, hvoraf mere senere.

En naturlig nøgle består af reelle data, nemlig data, der har et forhold til værdier i andre kolonner af rækken (eksempelvis skatteværdien koden for en person i en Kunder tabel, der også indeholder sin almindelighed). Selv en surrogat nøgle entydigt identificerer en række i en tabel, men dens værdi har ingen relation til andre værdier af den linje, og det er simpelthen genereres og lagres.

Vi analyserer fordele og ulemper ved de to typer af nøgler begynder med surrogat:

PRO

• En surrogat tasten har ingen relationer med de øvrige data linjen
• Hvis du har brug for at foretage ændringer i databasen med hensyn til ajourføring af det naturlige taster, kan man sagtens gøre uden at gå på kompromis med den fremmede nøgle relationer, hvis denne ikke er baseret på naturlige nøgler, men på et surrogat
• Den surrogat nøgler er normalt heltalsværdi og kræver derfor kun fire bytes til at gemme på denne måde at gøre strukturer mindre Performance Index (som har en positiv effekt af slutte sig til operationer)

MOD

• Hvis det sammenkædede tabeller i fremmed nøgle med en værdi surrogat er knyttet til en hovedtabellen, at få de faktiske værdier for sammenhæng mellem de forskellige tabeller, skal du deltage i operationer
• Det stedfortrædende nøglen er ikke meget nyttigt, når du søger efter specifikke oplysninger, har som de værdier, der er indeholdt i dem ingen reel mening

Med hensyn til den naturlige nøgler:

PRO

• Egner sig til forskning, fordi de værdier, der har reel betydning
• Kræver færre trin at få slutte nøgleværdier, fordi de er indeholdt i alle tabeller er involveret i tiltræder
• Egner sig til forskning, fordi de værdier, der har reel betydning

MOD

• Det er langt mere kompliceret opdateringen, især hvis den fremmede nøgle relationer til andre tabeller er baseret på dem
• Indekser antager større, fordi naturlige nøgler kræver typisk flere byte til at lagre
• Sammenføjninger baseret på sammensatte naturlige nøgler (som ofte omfatter string data) er langsommere end dem lavet med surrogat nøgler

• <<
• 1
• 2
• 3
• >>