Helyettesítő kulcs

Az oldal jelenlegi verzióját még nem nézték át tapasztalt közreműködők, és jelentősen eltérhet a 2016. június 13-án felülvizsgált verziótól ; az ellenőrzések 9 szerkesztést igényelnek .

A helyettesítő kulcs a relációs adatbázisok  elméletének fogalma .

Ez a tábla meglévő információs mezőihez hozzáadott kiegészítő szolgáltatásmező, amelynek egyetlen célja elsődleges kulcsként szolgálni . Ennek a mezőnek az értéke nem az adatbázisból származó egyéb adatok alapján kerül kialakításra , hanem mesterségesen generálódik.

Példa

Tegyük fel, hogy van két táblázatunk – „Emberek” és „Nyugták”. Egy személy azonosítása négy mező alapján történik - vezetéknév, keresztnév, családnév, születési dátum. A "Nyugták" táblázat jelzi, hogy pontosan kinek szól.

személy név1 | név2 | név3 | születési dátum | cím -------------------------------------------------- ------- Ivanov | Iván | Ivanovic | 1971. január 1. | utca. Wikipédia, 1 számla személy_név1 | személy_név2 | személy_név3 | személy_születési_dátuma | dátum | összeg | ki van fizetve -------------------------------------------------- ---------------------------------------------- Ivanov | Iván | Ivanovic | 1971. január 1. | 2011. február 1. | 2000,00 | Igen Ivanov | Iván | Ivanovic | 1971. január 1. | 2011. március 1. | 1000,00 | Nem

Ha mindkét táblához hozzáadunk egy technikai számmezőt (amelyet gyakran "id"-nek hívnak), akkor egy ilyen alapot kapunk.

személy azonosító | név1 | név2 | név3 | születési dátum | cím -------------------------------------------------- ---------------- 12345 | Ivanov | Iván | Ivanovic | 1971. január 1. | utca. Wikipédia, 1 számla azonosító | személyazonosító | dátum | összeg | ki van fizetve -------------------------------------------------- 56789 | 12345 | 2011. február 1. | 2000,00 | Igen 67890 | 12345 | 2011. március 1. | 1000,00 | Nem

A bizonylatok most nem „Ivanov Ivan Ivanovics, 1971. január 1-jén született”, hanem „12345. számú személy”-re vonatkoznak.

Megvalósítás

A helyettesítő kulcs általában egyszerűen egy numerikus mező, amely egy növekvő számsorból származó értékekkel van feltöltve. Ez megtehető triggerekkel vagy sorozatokkal . Számos DBMS-ben (például PostgreSQL , Sybase , MySQL [1] vagy SQL Server [2] ) létezik egy speciális adattípus az ilyen mezőkhöz - egy numerikus mező, amelyben, amikor egy rekordot hozzáadunk egy táblához, a tábla számára egyedi numerikus érték automatikusan kiírásra kerül - azaz n. "autoincrement" ( angolul  autoincrement ) vagy sorozat a PostgreSQL terminológiájában.

Abban az esetben, ha egy adatbázis potenciálisan használható lenne a replikációhoz, a numerikus mező nem biztosíthat egyediséget, és az UUID -k ilyen vagy olyan formában elsődleges elsődleges kulcsként kerülnek felhasználásra az egyediség biztosítása érdekében.

A

Állandóság. A helyettesítő kulcs fő előnye, hogy szinte soha nem változik, mivel nem hordoz semmilyen információt a tárgyterületről, ezért minimálisan függ a benne bekövetkező változásoktól. A helyettesítő kulcs megváltoztatása általában rendkívüli körülményeket igényel (lásd alább a „rugalmasság” okát).

A természetes kulcs attribútumai időről időre változhatnak - például egy személy megváltoztathatja a vezeték- vagy keresztnevét, új útlevelet kaphat az elveszett útlevél helyére. Ebben az esetben felmerül az úgynevezett „lépcsőzetes változtatások” igénye - a természetes kulcs értékének megváltoztatásakor a hivatkozási integritás megőrzése érdekében a rendszernek megfelelő változtatásokat kell végrehajtania az idegen kulcsok minden értékén, amely a kulcsra hivatkozik. kulcscsere folyamatban van. Nagy adatbázisokban ez jelentős többletköltséget jelenthet.

Garantált egyediség. Nem mindig garantálható, hogy a természetes kulcs egyedisége idővel nem sérül. Különféle külső tényezők vezethetnek oda, hogy egy korábban egyedi természetes kulcs új körülmények között elveszítheti egyediségét. A pótkulcs mentes ettől a hiányosságtól.

Rugalmasság. Mivel a helyettesítő kulcs nem tájékoztató jellegű, szabadon cserélhető. Tegyük fel, hogy két hasonló adatbázis-struktúrával rendelkező cég egyesül; a munkavállalót egy hálózati bejelentkezés azonosítja . Ahhoz, hogy a kulcs egyedi maradjon a létrejövő adatbázisban, hozzá kell adni egy további mezőt - „milyen cégtől jött”. Pótkulcsok esetén elegendő új kulcsokat kiadni valamelyik cég alkalmazottainak.

Hatékonyság. Ahogy a fenti példában is látható, a hivatkozásokat kényelmesebben egész számokként tároljuk, mint terjedelmes természetes kulcsokat. Ezen kívül a kérés

SELECT * FROM személy BELSŐ JOIN bill ON személy . id = számla . személy_azonosítója ;

kisebb és gyorsabb, mint

SELECT * FROM személy AS p BELSŐ JOIN bill AS b ON p . név1 = b . személy_név1 ÉS p . név2 = b . személy_név2 ÉS p . név3 = b . személy_név3 ÉS p . születési_dátum = b . személy_születési_dátuma ;

A programozás egyszerűsítése. Néhány programozási feladat például így leválasztható az adatbázis-struktúráról.

function getId ( $aTableName , $aFieldName , $aFieldValue ) { $sqFieldValue = mysql_real_escape_string ( $aFieldValue ); $qry = <<< QQQ SELECT id FROM `$aTableName` WHERE `$aFieldName`='$sqFieldValue'; QQQ ; if ( ! ( $eredmény = mysql_query ( $qry ))) die ( mysql_error ()); if ( ! ( $ar = mysql_fetch_array ( $eredmény ))) return null ; return $ar [ 0 ]; }

Ez a kód a PHP -ben, egy dinamikusan beírt nyelvben, már feltételezi, hogy csak egy kulcsmező van. A hagyományos nyelvekben, mint a C++ vagy a Java, a kulcsnak nem csak egyetlen mezőnek kell lennie, hanem valamilyen ismert típusú mezőnek. Ezért az ORM -ek az objektumhivatkozásokra támaszkodnak számokként vagy GUID -ként .

Hátrányok

Kulcsgenerátor sebezhetőségei. [3] Például a kulcsszámok alapján megtudhatja, hogy egy adott időszakban hány rekord jelent meg az adatbázisban.

Információ hiány. Az adatbázis kézi ellenőrzése bonyolultabbá válik, ott jelennek meg, INNER JOINahol nélkülözni is lehet. Emiatt a felsorolt ​​mezők gyakran rövid karakterlánc-billentyűket használnak.

sportoló ország azonosító | név1 | név2 | country_id id | név ---+----------+-------+----------- ----+-------- A1 | Ivanov | Iván | RUS RUS | Oroszország A2 | Petrenko | Péter | UKR UKR | Ukrajna A3 | Smith | János | USA USA | USA

Néha az adatok természetüknél fogva átvihetők adatbázisból adatbázisba (például helyi és központi adatbázis, kísérleti és működő verzió között). Az új adatok elfogadásakor a DBMS-nek saját helyettesítő kulcsokat kell generálnia azokhoz.

A rendszergazda kihagyja a normalizálást . A helyettesítő kulcsok hozzáadása egyszerűbb, mint helyes, figyelembe véve a duplikációt és az „1:∞” arányokat, oszd fel az adatbázist táblázatokra, és írj le egyedi indexeket .

Optimalizálási problémák. A DBMS-nek két indexet kell fenntartania , a helyettesítőt és a természetes indexet. Mint fentebb említettük, ott is megjelenhetnek, INNER JOINahol nincs rájuk szükség.

A fejlesztő akaratlan kötése a kulcsgenerátor viselkedéséhez egy adott DBMS-ben. Például a fejlesztő feltételezheti, hogy egy kisebb kulcsú üzenet korábban jelent meg.

Jegyzetek

  1. ↑ MySQL kézikönyv – Az AUTO_INCREMENT attribútum használata
  2. ↑ SQL Server 2008 Books Online – IDENTITY (tulajdon)
  3. ↑ Azok az átkozott növekményes azonosítók / Sudo Null IT News
 Adatbázis
Fogalmak
Objektumok
Kulcsok
SQL
Alkatrészek