Qual è la differenza tra la chiave primaria e il vincolo di chiave univoco?

Question

Qual è la differenza tra Primary key E unique Key constraint?

A che serve ??

Answer 1

Entrambi sono utilizzati per indicare candidate keys per una tabella.

È possibile avere una sola chiave primaria per una tabella, quindi è necessario selezionarne una solo se si dispone di più candidati.

Entrambi possono essere utilizzati in vincoli di chiave esterna. In SQL Server le colonne Chiave primaria non possono essere annullabili. Le colonne utilizzate nei vincoli delle chiavi univoche possono essere.

Per impostazione predefinita in SQL Server la chiave primaria diventa l'indice cluster se viene creata su un heap ma non è affatto obbligatorio che il PK e l'indice cluster siano uguali.

Answer 2

chiave primaria:

1. chiave primaria è altro che identifica in modo univoco ogni riga in una tabella.

2. La chiave primaria non consente valori duplicati, né NULL.

3. La chiave primaria per impostazione predefinita è un indice cluster.

4. Una tabella può avere solo una chiave primaria.

Chiave univoca:

1. Chiave univoca non è altro che identifica in modo univoco ogni riga in una tabella.

2. La chiave univoca non consente valori duplicati, ma consente (al massimo uno) NULL.

3. La chiave univoca predefinita è un indice non in cluster.

Questo è un frutto link completo per capire il Chiave primariaDatabase Keys. Tenete a mente abbiamo un solo indice cluster in una tabella [parlando di SQL Server 2005]. Ora se vogliamo aggiungere un'altra colonna univoca, useremo la colonna , perché la colonna Chiave univoca può essere aggiunta più di una.

Answer 3

Una chiave primaria è quella che viene utilizzata per identificare la riga in questione. Potrebbe anche avere un significato al di là di questo (se esistesse già un pezzo di dati "reali" che potrebbero servire) o potrebbe essere puramente un artefatto di implementazione (la maggior parte delle colonne IDENTITY e valori equivalenti auto-incrementati su altri sistemi di database).

Una chiave univoca è un caso più generale, in cui una chiave non può avere valori ripetuti. Nella maggior parte dei casi le persone non possono avere gli stessi numeri di previdenza sociale in relazione alla stessa giurisdizione (un caso internazionale potrebbe essere diverso). Quindi, se stessimo memorizzando i numeri di previdenza sociale, allora vorremmo modellarli come unici, come ogni caso che corrispondano a un numero esistente è chiaramente sbagliato. I nomi utente in genere devono essere anche unici, quindi ecco un altro caso. Gli identificatori esterni (identificatori utilizzati da un altro sistema, standard o protocollo) tendono ad essere anche univoci, ad es. c'è solo un linguaggio con un determinato codice ISO 639, quindi se stessimo memorizzando i codici ISO 639 lo modelleremo come unico.

Questa univocità può trovarsi anche su più di una colonna. Ad esempio, nella maggior parte dei sistemi di categorizzazione gerarchica (ad es. Una struttura di cartelle) nessun elemento può avere sia lo stesso articolo genitore che lo stesso nome, anche se potrebbero esserci altri articoli con lo stesso genitore e nomi diversi, e altri con lo stesso nome e diversi i genitori. Questa funzionalità multi-colonna è presente anche sulle chiavi primarie.

Una tabella può anche avere più di una chiave univoca. Per esempio. un utente può avere sia un numero identificativo che un nome utente, ed entrambi dovranno essere unici.

Qualsiasi chiave univoca non annullabile può quindi servire come chiave primaria. A volte le chiavi primarie che provengono dai dati innati che vengono modellati sono indicate come "chiavi primarie naturali", perché sono una parte "naturale" dei dati, piuttosto che un semplice artefatto di implementazione. La decisione su quale utilizzare dipende da alcune cose:

1. Probabilità di modifica delle specifiche. Se abbiamo modellato un numero di previdenza sociale come unico e quindi abbiamo dovuto adattarlo per consentire giurisdizioni multiple in cui due o più utilizzano un sistema di numerazione abbastanza simile per consentire le collisioni, è probabile che sia sufficiente rimuovere il vincolo di unicità (altre modifiche potrebbero essere necessarie). Se era la nostra chiave primaria, ora abbiamo anche bisogno di usare una nuova chiave primaria e modificare qualsiasi tabella che utilizzava quella chiave primaria come parte di una relazione e qualsiasi query che si è unita su di essa.

2. Velocità di ricerca. L'efficienza chiave può essere importante, in quanto vengono utilizzate in molte clausole WHERE e (più spesso) in molti JOIN s. In particolare, con JOINS, la velocità di ricerca può essere vitale. L'impatto dipenderà dai dettagli dell'implementazione, e diversi database variano a seconda di come gestiranno diversi tipi di dati (io avrei pochi scrupoli dal punto di vista delle prestazioni nell'usare una grande porzione di testo come chiave primaria in Postgres dove potrei specificare l'uso di hash si unisce, ma sarei molto titubante a farlo in SQLServer [Modifica: per "grande", sto pensando forse alla dimensione di un nome utente, non qualcosa delle dimensioni di tutti gli Eddas norreni!]).

3. Frequenza della chiave come unici dati interessanti. Ad esempio, con una tabella di lingue e una tabella di parti di commenti in quella lingua, molto spesso l'unica ragione per cui vorrei unirmi alla tabella della lingua quando si ha a che fare con la tabella dei commenti è ottenere il codice della lingua o limitare una query a quelli con un particolare codice di lingua. Altre informazioni sulla lingua potrebbero essere usate molto più raramente. In questo caso, è probabile che l'adesione al codice sia meno efficiente di un ID numerico impostato da una colonna IDENTITY, con il codice come chiave primaria e quindi come ciò che è memorizzato nella colonna chiave esterna nella tabella dei commenti - eliminerà la necessità di qualsiasi JOIN, con un notevole guadagno di efficienza. Più spesso, anche se desidero ricevere più informazioni dalle tabelle pertinenti, rendere più efficiente la JOIN è più importante.

Answer 4

Versione corta:

• Dal punto di vista della teoria dei database, non c'è nessuno. Entrambi sono semplicemente tasti candidati.
• In pratica, alla maggior parte dei DMBS piace avere una "chiave standard", che può essere utilizzata per es. decidere come memorizzare i dati e comunicare agli strumenti e ai client DB quale sia il modo migliore per identificare un record.

Quindi distinguere una chiave univoca come "chiave primaria" è solo una comodità di implementazione (ma importante).

Answer 5

Una chiave primaria è una qualsiasi chiave candidato. In linea di principio le chiavi primarie non sono diverse da qualsiasi altra chiave candidata poiché tutte le chiavi sono uguali nel modello relazionale.

SQL tuttavia ha due diverse sintassi per l'implementazione delle chiavi candidate: il vincolo PRIMARY KEY e il vincolo UNIQUE (su colonne non annullabili, ovviamente). In pratica ottengono esattamente la stessa cosa tranne la restrizione essenzialmente inutile che una PRIMARY KEY può essere utilizzata solo una volta per tabella mentre un vincolo UNIQUE può essere usato più volte.

Quindi non esiste un "uso" fondamentale per il vincolo PRIMARY KEY. È ridondante e potrebbe essere facilmente ignorato o eliminato dalla lingua del tutto. Tuttavia, molte persone trovano conveniente individuare una particolare chiave per tabella che abbia un significato speciale. C'è una convenzione molto diffusa che le chiavi designate con PRIMARY KEY sono usate per riferimenti a chiavi esterne, sebbene questo sia del tutto opzionale.

Answer 6

Sia la chiave primaria che la chiave univoca vengono utilizzate per applicare l'unicità di una colonna. Quindi, quando scegli l'una rispetto all'altra?

Una tabella può avere solo una chiave primaria. Se si desidera applicare l'univocità su 2 o più colonne, viene utilizzato il vincolo di chiave univoco.

Differenza tra il vincolo di chiave primaria e il vincolo di chiave Univoco?

1. Una tabella può avere una sola chiave primaria, ma più tasti

2. chiave primaria unica non consente i null, dove tonalità unico permette uno nullo

ALTER TABLE Table_Name 
ADD CONSTRAINT Constraint_Name PRIMARY KEY (Column_Name) 

Alter Table Table_Name 
Add Constraint Constraint_Name Unique(Column_Name)