- Cosa sono le chiavi?
- Chiavi semplici
- Chiavi concatenate o composte
- Chiavi primarie
- Numerazione e incremento automatico
- Una tabella può contenere più chiavi primarie?
Mentre molti sviluppatori e amministratori di database possono lavorare con primary keys ogni giorno, è un argomento affascinante chiedersi:"Che cosa è esattamente una primary key e può (o dovrebbe) una tabella di database contenere più primary keys contemporaneamente?"
Di seguito esamineremo queste domande in modo più dettagliato e cercheremo di raggiungere un consenso ragionevole e generalmente concordato all'interno della comunità di sviluppo.
Cosa sono le chiavi?
Per capire cos'è una primary key è in una tabella di database, dobbiamo prima capire un po' le non-primary keys . Una key in una tabella è semplicemente un attributo che viene utilizzato per identificare e accedere a tali informazioni. Una tabella può e spesso avrà più chiavi, come nella tabella Users entrambi email e username potrebbero essere considerate chiavi.
A seconda dello sviluppatore o dell'amministratore con cui stai parlando, potresti sentire parlare di una varietà di tipi di chiavi e delle loro definizioni, quindi tratteremo solo alcuni esempi diversi di seguito e una definizione di base di ciascuno.
Chiavi semplici
Una simple key è solo una chiave che utilizza un solo attributo nella tabella. A meno che non imponiamo più restrizioni sulla chiave o sulla tabella, allora il username l'attributo nell'esempio sopra è una simple key .
Chiavi concatenate o composte
Un ulteriore passo avanti rispetto a simple keys sono concatenated o compound chiavi. Come suggerisce il nome, una concatenated key è un'unione di più single keys . Ad esempio, il sistema può combinare automaticamente il last_name e year_of_birth single keys in una concatenated key , in questo modo:smith1980 .
Chiavi primarie
Un [primary key](https://en.wikipedia.org/wiki/Unique_key) è una chiave che è stata scelta come principale (o primaria ) attributo rappresentativo per quella riga di dati. La primary key è unico e quell'attributo viene quindi utilizzato in tutto il database e viene acceduto e passato ad altre tabelle come attributo rappresentativo per i dati in questione.
In pratica, la primary key l'attributo è anche contrassegnato come NOT NULL nella maggior parte dei database, ciò significa che l'attributo deve sempre contenere un valore per il record da inserire nella tabella.
Ad esempio, l'email o username simple keys potrebbe ricevere la designazione della primary key , ma in genere è consigliabile impostare la primary key a un attributo che non è (o non potrebbe) essere modificato né dalla logica aziendale né dall'individuo. Ad esempio, immagina un User ottiene un nuovo indirizzo e-mail, che quindi causa tutte le primary key passate associazioni effettuate utilizzando il vecchio indirizzo email per diventare non valide quando si utilizza il nuovo indirizzo email.
Per questo motivo (tra gli altri), la maggior parte delle primary keys usa un numero o una stringa univoca, come un [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) .
Numerazione e incremento automatico
Vale anche la pena notare brevemente che molti sistemi di database sono impostati in modo tale che ogni tabella abbia una primary key che è sia numerico che incrementato automaticamente. Ciò significa semplicemente che il motore di database stesso assegna automaticamente a ogni nuovo record in quella tabella una primary key univoca valore che è incrementalmente maggiore di tutti i valori precedenti. Tuttavia, la maggior parte degli sviluppatori concorda sul fatto che questa pratica non è aggiornata ed espone inutili falle di sicurezza per il sistema quando viene utilizzata per alcuni tabelle che rappresentano determinati dati.
Ad esempio, immagina tutti gli User ai record viene assegnata una primary key con incremento automatico valore, noto come id attributo. Se una persona malintenzionata scopre che l'id l'attributo di un determinato utente (ad es. John Smith) è il valore 1500 , questo espone già un po' di informazioni. In primo luogo, indica che è probabile che ci siano almeno 1499 altri utenti nel sistema, o che a un certo punto c'erano. Significa anche che se è possibile accedere alla pagina utente di John Smith tramite un URL o una chiamata API che contiene quel id valore di 1500 , allora è molto probabile che cambi semplicemente il valore con un altro numero, ad esempio 1499 o 1501 , esporrà la pagina di un altro utente che potrebbe non volere che la propria pagina acceda a questo visitatore. In questo modo, i record possono essere interrogati semplicemente indovinando l'id valori su scala di massa.
Questi sono ovviamente esempi molto semplici, ma per questi motivi la maggior parte dei database moderni utilizzerà una primary key univoca e randomizzata valore di attributo come un UUID quando si lavora con dati sensibili.
Una tabella può contenere più chiavi primarie?
La risposta breve è no , una tabella non può contenere più primary keys , in quanto ciò va contro i principi fondamentali della progettazione di database relazionali (vedi:[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) e [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) ).
è possibile che un tavolo abbia più candidate keys , che effettivamente si comportano in modo simile a una primary key in esso una candidate key è unico, NOT NULL , ed è una rappresentazione singolare di quel record di tabella.
Tuttavia, quando si tratta di selezionare quale uno l'attributo verrà assegnato come primary key per la tabella, la scelta viene dall'elenco di tutte le potenziali candidate keys (da cui il nome, sono candidati a diventare una primary key ). Alla fine, solo una candidate key è selezionato come attributo più rappresentativo per quel record, da utilizzare in questa tabella come primary key e referenziato altrove nel database da altre tabelle tramite le rispettive foreign keys .
