2009-11-17 13 views

risposta

23

Se si intende "una chiave primaria in SQL ha più colonne", la risposta è sì.

+0

grazie! sì, è quello che intendevo – Gal

+5

Un'altra buona domanda è DOVREBBE che una chiave primaria sia costituita da più colonne. :) –

+6

Beh, questa è una domanda diversa, e la risposta è NO, NON MAI, E SE LO FACCIO TI CERCER DOWN E TI FER H. Solo una preferenza personale, ovviamente :-) – Stu

6

Se stai chiedendo se una tabella può avere più colonne come chiave primaria, quindi per MS SQL Server, la risposta è sì, e si chiama una chiave composita (corretta).

+0

@Charles Grazie! modificato. – Joseph

28

Una tabella può avere solo un vincolo di chiave primaria, ma può essere costituito da più colonne, ad es.

create table my_table (col1 integer, col2 integer, col3 integer, 
    primary key (col1, col2, col3) 
    ); 

Oltre alla chiave primaria, una tabella può anche avere uno o più vincoli UNIQUE, ad es.

create table my_table2 (col1 integer, col2 integer, col3 integer, 
    primary key (col1, col2), 
    unique (col2, col3) 
    ); 
+0

grazie mille! – Gal

+0

Sebbene una tabella possa avere solo una chiave primaria, (solo per definizione) può avere un numero qualsiasi di chiavi, ognuna delle quali può essere designata come chiave primaria.(Gli altri saranno quindi indicati come chiavi "alternate") –

+1

Interessante .. quindi se una chiave univoca si trova su più colonne vuol dire che col2.col3 sono unici (insieme) O vuol dire che col2 è univoco e col3 è unico? – Mark

0

In genere una chiave composta è una pratica scadente. Farà in modo che le cose siano più lente quando hai bisogno di unirti ad esso. È anche più difficile quando è necessario aggiornare uno o più campi in 27 tabelle figlio. Una pratica migliore è una chiave surrogata e un indice univoco sui campi che normalmente costituiscono la chiave composta. Quindi hai la velocità del join intero e l'attributo univoco viene mantenuto e quando cambia il valore della chiave (come spesso accade in una chiave composta), devi solo cambiare una tabella invece di tutte le tabelle figlio.

C'è un posto in cui userò comunque una chiave composta e che è una tabella di mappatura che viene utilizzata per creare le relazioni reali per una relazione molti-a-molti. In questo caso di solito hai solo due colonne ed entrambi sono in genere numeri interi che normalmente non cambiano. Quindi di solito uso una chiave composta in quanto questo caso particolare non ha gli svantaggi di un composito in una tabella normale.

+0

Per fare un punto preciso, (ma penso che sia importante) le chiavi hanno due scopi distinti. 1. Una chiave Unica in una tabella garantisce la coerenza dei dati all'interno della tabella (nessuna riga duplicata logicamente). A tal fine, se la "chiave naturale" è composta, la chiave è composta. fine della storia. Nessun'altra chiave 'più semplice' garantirà la coerenza dei dati. Ma questa funzione non ha alcun impatto sulle prestazioni, quindi non c'è alcun impatto sulle prestazioni dall'uso della chiave composita corretta. –

+0

2. In secondo luogo, le chiavi univoche (Prim o alternativa) vengono utilizzate come destinazioni per le chiavi esterne nelle tabelle correlate per garantire che esistano valori di Chiave Foerign. A tal fine, più breve è la chiave, migliori sono le prestazioni. quindi, l'uso di una chiave non naturale (o surrogata) che non contiene alcun significato, per raggiungere questo secondo scopo aumenta le prestazioni. Allora perché non usare entrambi dove esistono entrambi i bisogni e la chiave naturale è composta, o troppo lunga, da perforare ?? –

4

"Di solito una chiave composta è una pratica scadente."

Attenzione ai falsi profeti che cercano di venderti una tale schifezza.

Una chiave è una chiave è una chiave è una chiave. Una chiave IS un set di attributi. Niente di più e niente di meno. La cardinalità di quel set può essere 1, o può essere> 1, e può ANCHE ESSERE ZERO! E una chiave corrisponde, uno a uno, a un vincolo di unicità.

Il modello relazionale NON HA PRESCRIZIONE COSA SEMPRE MAI che un vincolo di chiave/univocità possa coinvolgere solo un singolo attributo.

Inoltre, il modello relazionale non ha alcuna motivazione quanto mai contraria alla presenza di più di una chiave, ed è ANCHE un fatto che la teoria relazionale ha abbandonato il concetto (per decenni già) di "chiave primaria" (che implica che una tale chiave "primaria" sarebbe in ogni senso "più di una chiave" rispetto agli altri), perché completamente inutile e irrilevante. Per quanto riguarda l'unicità delle chiavi, TUTTI i tasti sono uguali (e NON è il caso che una particolare chiave è più uguale delle altre).

+1

-1. No, non tutte le chiavi sono uguali ... Le chiavi composte sono più lente per le ricerche di chiavi esterne rispetto alle chiavi a colonna singola. E una chiave "naturale" (basata sulla definizione dei dati del modello di dominio reale) è intrinsecamente diversa da una chiave surrogata priva di significato (non è affatto la stessa cosa se non l'unicità di valore della riga della tabella senza significato). Utilizzare entrambi quando sono richiesti entrambi. –

+1

Non so se dovrei votare più o meno. Sono d'accordo con la prima parte, ma non sono d'accordo sul fatto che tutte le chiavi siano uguali. Le chiavi primarie per definizione devono essere uniche. Le chiavi esterne possono essere nulle, utilizzate una volta (relazione one-to-one) o ripetute (qualunque sia il design del database richiesto). –

+1

Tutte le chiavi che definiscono l'unicità sono ugualmente uniche. Le chiavi esterne non sono le chiavi che definiscono l'unicità. Non stavo parlando di quelli. È stato un enorme errore chiamare questo concetto una "chiave". Naturalmente, se si usano le chiavi composite per qualche relvar/tabella/entità, e in un'altra relvar/tabella/entità si deve "fare riferimento" alla prima, allora ci sarà bisogno di una chiave esterna composita in quella "altra" relvar/tabella /entità. –

Problemi correlati