Gebruik en beheer van de identiteit kolommen in SQL Server

Bij het ​​ontwerpen van een database om toepassingen te ondersteunen is het van essentieel belang na te gaan hoe de primaire sleutels af te handelen. Er zijn in dit verband ten minste twee scholen van denken: een die stelt dat het juiste ding om te doen is gebruik maken van de zogenaamde surrogate keys (dwz niet gebaseerd op echte gegevens) en een andere die beweert dat moet in plaats van werkelijke gegevens zijn zoals gebruikt kernwaarden. Dan is er een middenweg die bestaat uit 'een database voor gebruik in beide van deze oplossingen, afhankelijk van de relatieve voor-en nadelen (die we binnenkort).

Bij het ontwerpen van een tabel bevat meestal een of meer kolommen die deel uitmaken van de primaire sleutel. Zoals we weten een tabel de primaire sleutel is een waarde (of een combinatie van waarden), dat uniek is voor elke rij. Zoals eerder vermeld, als een sleutel bestaat uit reële waarden heet natuurlijke sleutel, maar als bijvoorbeeld de sleutel wordt gegenereerd telkens als u een rij wilt invoegen in de tabel heet surrogate key. Een surrogaat sleutel is meestal een numerieke waarde in SQL Server, en vaak de kolommen van dit type zijn die van identiteit, waarover later meer.

Een natuurlijke sleutel is opgebouwd uit echte gegevens, dat wil zeggen gegevens die een relatie met waarden in andere kolommen van de rij (bijvoorbeeld de BTW-code van een individu in een tabel Klanten die bevat ook zijn algemeenheid) zijn. Zelfs een surrogate key identificeert een rij in een tabel, maar zijn waarde heeft geen betrekking op andere waarden van de lijn en is het eenvoudig gegenereerd en opgeslagen.

We analyseren de voor-en nadelen van de twee types van sleutels die beginnen met het surrogaat:

De PRO

• Een surrogate key heeft geen betrekkingen met de andere data lijn
• Als u wijzigingen moet aanbrengen in de database met betrekking tot de actualisering van de natuurlijke toetsen die gemakkelijk kan worden gedaan zonder afbreuk te doen aan de refererende sleutel relaties, maken indien deze niet gebaseerd zijn op natuurlijke toetsen, maar op een surrogaat
• De surrogate keys zijn meestal integer waarde en vereisen daarom slechts vier bytes op te slaan op deze manier het maken van structuren kleiner-index (dat heeft een positief effect join operaties)

TEGEN DE

• Als de gekoppelde tabellen in foreign key met een waarde surrogaat is gekoppeld aan een van de belangrijkste tafel, om de werkelijke waarden van de verbinding tussen de verschillende tabellen te krijgen moet u aan operaties
• De surrogaat sleutel is niet erg handig bij het zoeken naar specifieke informatie, zoals de waarden in hen hebben geen echte betekenis

Als voor de natuurlijke toetsen:

De PRO

• Lenen zich voor onderzoek, omdat de waarden zijn werkelijke betekenis
• Vereisen minder stappen aan te sluiten bij kernwaarden te krijgen, omdat ze zijn opgenomen in alle tabellen die betrokken zijn in joins
• Lenen zich voor onderzoek, omdat de waarden zijn werkelijke betekenis

TEGEN DE

• Het is veel ingewikkelder update, vooral als de refererende sleutel relaties met andere tabellen zijn gebaseerd op hun
• Indexen nemen groter omdat natuurlijke toetsen vergen doorgaans meer bytes op te slaan
• Sluit zich aan op basis van samengestelde natuurlijke toetsen (die vaak ook string data) zijn langzamer dan die gemaakt met surrogate keys

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