Come prefazione, si noti che una chiave primaria non deve essere una singola colonna:può essere composta da più colonne:questa è nota come chiave composita. Nota inoltre che non tutte le tabelle hanno un AUTO_INCREMENT /IDENTITY colonna e puoi avere un UNIQUE vincolo comunque su una singola colonna all'interno di una chiave composta.
-
Non ce n'è, ma non ha senso che un DBMS vieti tale ridondanza o perché avresti bisogno di logica e complessità aggiuntive per gestire quella condizione, mentre non c'è alcun danno reale avendo entrambi (oltre all'impatto sulle prestazioni di dover mantenere due indici).
-
Come detto sopra:perché il costo opportunità di rilevare e prevenire che la ridondanza non valga la pena.
Un'altra cosa da considerare è che la definizione di chiave primaria di una tabella non è immutabile e quindi è soggetta a modifiche. Una tabella potrebbe già avere colonne con un UNIQUE impostazione del vincolo e quindi il progettista del database decide di includerlo in una nuova definizione della chiave primaria - sarebbe poco facile per l'utente richiedere che il vecchio vincolo venga rimosso prima, specialmente se altre parti del loro sistema applicativo dipendono da quel vincolo UNICO presente (ad es. un 1:0..1 definizione della relazione).
(Inoltre, AUTO_INCREMENT non è mutualmente inclusivo con UNIQUE o PRIMARY KEY :puoi usare AUTO_INCREMENT con colonne non univoche (ad es. se AUTO_INCREMENT viene aggiunto dopo che una tabella contiene già dei dati), e viceversa una PRIMARY KEY può utilizzare valori univoci provenienti da altre fonti, come un'altra colonna di identità come chiave esterna (le chiavi primarie composite possono contenere chiavi esterne!) o un'origine dati "naturale", come l'utilizzo di un numero di previdenza sociale statunitense come chiave primaria (ovviamente non dovresti mai fallo in realtà)).
