Surrogatnyckel

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 13 juni 2016; kontroller kräver 9 redigeringar .

Surrogatnyckel  är ett begrepp inom teorin om relationsdatabaser .

Detta är ett ytterligare servicefält som läggs till de befintliga informationsfälten i tabellen, vars enda syfte är att fungera som en primärnyckel . Värdet på detta fält bildas inte på grundval av någon annan data från databasen , utan genereras på konstgjord väg.

Exempel

Anta att vi har två tabeller - "Personer" och "Kvitton". En person identifieras med fyra fält - efternamn, förnamn, patronym, födelsedatum. Tabellen "Kvitton" anger exakt vem den är adresserad till.

person namn1 | namn2 | namn3 | födelsedatum | adress -------------------------------------------------- ------- Ivanov | Ivan | Ivanovic | 1 januari 1971 | st. Wikipedia, 1 räkningen person_name1 | person_name2 | person_name3 | person_födelsedatum | datum | belopp | är betalad -------------------------------------------------- ---------------------------------------------------- Ivanov | Ivan | Ivanovic | 1 januari 1971 | 1 februari 2011 | 2000,00 | Ja Ivanov | Ivan | Ivanovic | 1 januari 1971 | 1 mars 2011 | 1000,00 | Nej

Genom att lägga till ett tekniskt nummerfält (ofta kallat "id") till båda tabellerna får vi en sådan bas.

person id | namn1 | namn2 | namn3 | födelsedatum | adress -------------------------------------------------- --------------- 12345 | Ivanov | Ivan | Ivanovic | 1 januari 1971 | st. Wikipedia, 1 räkningen id | person_id | datum | belopp | är betalad -------------------------------------------------- 56789 | 12345 | 1 februari 2011 | 2000,00 | Ja 67890 | 12345 | 1 mars 2011 | 1000,00 | Nej

Nu hänvisar kvittonen inte till "Ivanov Ivan Ivanovich, född 1 januari 1971", utan till "person nr 12345".

Implementering

Vanligtvis är en surrogatnyckel helt enkelt ett numeriskt fält fyllt med värden från en stigande numerisk sekvens. Detta kan göras med triggers eller sekvenser . I ett antal DBMS (till exempel PostgreSQL , Sybase , MySQL [1] eller SQL Server [2] ) finns det en speciell datatyp för sådana fält - ett numeriskt fält, där, när en post läggs till i en tabell, ett numeriskt värde som är unikt för denna tabell skrivs automatiskt - dvs n. "autoincrement" ( engelska  autoincrement ) eller seriell i PostgreSQL-terminologi.

I händelse av att en databas potentiellt skulle kunna användas i replikering, kan ett numeriskt fält inte ge unikhet, och UUID i en eller annan form används som primära surrogatnycklar för att säkerställa unikhet.

Skäl till att använda

Oföränderlighet. Den största fördelen med en surrogatnyckel är att den nästan aldrig ändras, eftersom den inte innehåller någon information från ämnesområdet och därför är minimalt beroende av förändringar som sker i det. Att byta en surrogatnyckel kräver vanligtvis extraordinära omständigheter (se skälet till "flexibilitet" nedan).

Naturliga nyckelattribut kan ändras från tid till annan - till exempel kan en person ändra sitt för- eller efternamn, få ett nytt pass för att ersätta ett förlorat. I det här fallet uppstår behovet av så kallade "kaskadändringar" - när man ändrar värdet på en naturlig nyckel, för att upprätthålla referensintegritet , måste systemet göra lämpliga ändringar av alla värden på främmande nycklar som hänvisar till nyckeln ändras. I stora databaser kan detta vara en betydande overhead.

Garanterad unikhet. Det är långt ifrån alltid möjligt att garantera att det unika med en naturlig nyckel inte kommer att äventyras över tid. Olika yttre faktorer kan leda till att en tidigare unik naturlig nyckel kan förlora sin unikhet under nya omständigheter. En surrogatnyckel är fri från denna brist.

Flexibilitet. Eftersom surrogatnyckeln är icke-informativ kan den fritt bytas ut. Antag att två företag med en liknande databasstruktur går samman; medarbetaren identifieras av en nätverksinloggning . För att nyckeln ska förbli unik i den resulterande databasen måste du lägga till ett extra fält i den - "vilket företag kom du ifrån". När det gäller surrogatnycklar räcker det att ge ut nya nycklar till anställda i ett av företagen.

Effektivitet. Som visas i exemplet ovan lagras referenser mer bekvämt som heltal än som skrymmande naturliga nycklar. Därtill kommer begäran

VÄLJ * FRÅN person INNER JOIN räkning PÅ person . id = räkning . person_id ;

mindre och snabbare än

VÄLJ * FRÅN person AS p INNER JOIN bill AS b ON p . namn1 = b . person_name1 OCH p . namn2 = b . person_name2 OCH p . namn3 = b . person_name3 OCH p . födelsedatum = b . person_födelsedatum ;

Förenkling av programmering. Vissa programmeringsuppgifter kan kopplas bort från databasstrukturen, till exempel på detta sätt.

funktion getId ( $aTableName , $aFieldName , $aFieldValue ) { $sqFieldValue = mysql_real_escape_string ( $aFieldValue ); $qry = <<< QQQ VÄLJ ID FRÅN `$aTableName` WHERE `$aFieldName`='$sqFieldValue'; QQQ ; if ( ! ( $result = mysql_query ( $qry ))) dö ( mysql_error ()); if ( ! ( $ar = mysql_fetch_array ( $result ))) returnerar null ; returnera $ar [ 0 ]; }

Denna kod i PHP , ett dynamiskt skrivet språk, förutsätter redan att det bara finns ett nyckelfält. I traditionella språk som C++ eller Java bör nyckeln inte bara vara ett enstaka fält, utan ett fält av någon känd typ. Därför förlitar sig ORM:er på att objektreferenser är nummer eller GUID:er .

Nackdelar

Nyckelgenerators sårbarheter. [3] Till exempel kan du genom nyckelnummer ta reda på hur många poster som förekom i databasen under en viss period.

Brist på information. Den manuella kontrollen av databasen blir mer komplicerad, de dyker upp INNER JOINdär du kan klara dig utan dem. Av denna anledning använder uppräknade fält ofta korta strängnycklar.

idrottsmans land id | namn1 | namn2 | country_id id | namn ---+----------+-------+----------- ----+------- A1 | Ivanov | Ivan | RUS RUS | Ryssland A2 | Petrenko | Peter | UKR UKR | Ukraina A3 | Smith | John | USA USA | USA

Ibland är data till sin natur föremål för överföring från databas till databas (till exempel mellan en lokal och centraliserad databas, experimentell och fungerande version). När nya data accepteras måste DBMS generera sina egna surrogatnycklar för dem.

Får administratören att hoppa över normalisering . Att lägga till surrogatnycklar är lättare än korrekt, med hänsyn till duplicering och "1:∞"-förhållanden, dela upp databasen i tabeller och lägg ner unika index .

Optimeringsproblem. DBMS måste upprätthålla två index , surrogat och naturligt. Som nämnts ovan kan de dyka upp INNER JOINdär de inte behövs.

Ofrivillig bindning av utvecklaren till beteendet hos nyckelgeneratorn i en viss DBMS. Till exempel kan utvecklaren anta att ett meddelande med en mindre nyckel dök upp tidigare.

Anteckningar

  1. ↑ MySQL Referensmanual - Använda attributet AUTO_INCREMENT
  2. ↑ SQL Server 2008 Books Online - IDENTITET (egenskap)
  3. ↑ Dessa jävla inkrementella ID:n / Sudo Null IT News
 Databas
Begrepp
Objekt
Nycklar
SQL
Komponenter