80

Questo esempio viene preso from w3schools.Perché utilizzare più colonne come chiavi primarie (chiave primaria composta)

CREATE TABLE Persons 
(
    P_Id int NOT NULL, 
    LastName varchar(255) NOT NULL, 
    FirstName varchar(255), 
    Address varchar(255), 
    City varchar(255), 
    CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName) 
) 

mia comprensione è che entrambe le colonne insieme (P_Id e LastName) rappresentano una chiave primaria per la tabella Persons. È corretto?

  • Perché qualcuno dovrebbe utilizzare più colonne come chiavi primarie anziché una singola colonna?
  • Quante colonne possono essere utilizzate insieme come chiave primaria in una data tabella?
+0

... ora c'è anche un [risposta per il 2'nd question] (http://stackoverflow.com/a/41741054/2932052) – Wolf

risposta

97

La tua comprensione è corretta.

Lo farebbe in molti casi. Un esempio è in una relazione come OrderHeader e OrderDetail. Il PK in OrderHeader potrebbe essere OrderNumber. Il PK in OrderDetail potrebbe essere OrderNumber E LineNumber. Se fosse uno di questi due, non sarebbe unico, ma la combinazione dei due è garantita unica.

L'alternativa è utilizzare una chiave primaria generata (non intelligente), ad esempio in questo caso OrderDetailId. Ma allora non vedresti sempre la relazione facilmente. Alcuni preferiscono un modo; alcuni preferiscono l'altro modo.

+0

È questo utile se sto usando branch_id e utilizzo della replica tra due database, risolverò duplicati di ID? !! – Mhmd

+5

Si noti che in molti casi di utilizzo di una chiave primaria generata, spesso si desidera comunque una chiave univoca sui valori compositi. –

2

Sì, entrambi formano la chiave primaria. Soprattutto nelle tabelle in cui non si dispone di un surrogate key, potrebbe essere necessario specificare più attributi come identificativo univoco per ogni record (esempio errato: una tabella con sia un nome che un cognome potrebbe richiedere la combinazione di essi per essere univoci).

20

Un altro esempio di chiavi primarie composte è l'utilizzo delle tabelle di associazione. Supponiamo di avere una tabella di persone che contiene un gruppo di persone e una tabella di gruppo che contiene un gruppo di gruppi. Ora vuoi creare una relazione molte a molte di persona e di gruppo. Il significato di ogni persona può appartenere a molti gruppi. Ecco come apparirà la struttura della tabella utilizzando una chiave primaria composta.

Create Table Person(
PersonID int Not Null, 
FirstName varchar(50), 
LastName varchar(50), 
Constraint PK_Person PRIMARY KEY (PersonID)) 

Create Table Group (
GroupId int Not Null, 
GroupName varchar(50), 
Constraint PK_Group PRIMARY KEY (GroupId)) 

Create Table GroupMember (
GroupId int Not Null, 
PersonId int Not Null, 
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId), 
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId), 
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID)) 
+0

grande spiegazione: penso che la necessità di attributi per le relazioni m-to-n (in una fasion normalizzata) sia la chiave. – Wolf

8

L'esempio W3Schools non dice quando si dovrebbe usare chiavi primarie composte, e sta dando solo esempio di sintassi utilizzando la stessa tabella di esempio per altre chiavi.

La loro scelta di esempio è forse fuorviante combinando una chiave senza significato (P_Id) e una chiave naturale (LastName). Questa strana scelta della chiave primaria dice che le seguenti righe sono valide secondo lo schema e sono necessarie per identificare univocamente uno studente. Intuitivamente questo non ha senso.

1234  Jobs 
1234  Gates 

Letture consigliate: The great primary-key debate o semplicemente Google meaningless primary keys o anche esaminare questo SO question

FWIW - I miei 2 centesimi è quello di evitare le chiavi primarie a più colonne e utilizzare un singolo campo id generato (chiave surrogata) come il chiave primaria e aggiungere ulteriori vincoli (univoci) ove necessario.

2

Più colonne in una chiave, in generale, hanno prestazioni inferiori a quelle di una chiave surrogata. Preferisco avere una chiave surrogata e quindi un indice univoco su una chiave a più colonne. In questo modo puoi avere prestazioni migliori e mantenere l'unicità necessaria.E ancora meglio, quando uno dei valori in quella chiave cambia, non è necessario aggiornare un milione di voci figlio in 215 tabelle figlio.

2

Si utilizza una chiave composta (una chiave con più di un attributo) ogni volta che si desidera garantire l'univocità di una combinazione di più attributi. Una singola chiave attributo non raggiungerebbe la stessa cosa.

+1

Come per garantire una chiave univoca, si potrebbe fare affidamento sulla combinazione di due attributi per formare una chiave che non può essere duplicata in modo logico, la data di Persona e di graduazione da un set di dati più grande sarebbe un esempio. –

0

L'utilizzo di una chiave primaria su più tabelle è utile quando si utilizza una tabella intermedia in un database relazionale.

Utilizzerò un database che ho creato per un esempio e in particolare tre tabelle all'interno di tale tabella. I cre ä ted un database per un webcomic alcuni anni fa. Un tavolo si chiamava "fumetti" — un elenco di tutti i fumetti, i loro titoli, il nome del file immagine, ecc. La chiave primaria era "comicnum".

Il secondo tavolo era "caratteri" — i loro nomi e una breve descrizione. La chiave primaria era su "charname".

Poiché ogni fumetto — con alcune eccezioni — aveva più caratteri e ogni personaggio appariva in più fumetti, non era pratico mettere una colonna in "caratteri" o "fumetti" per riflettere ciò. Invece, ho creato uno terzo terzo tavolo chiamato "comicchars", e quello era un elenco di quali caratteri apparivano in quali fumetti. Poiché questa tabella essenzialmente si univa alle due tabelle, aveva bisogno di due colonne: charname e comicnum e la chiave primaria era su entrambe.

2

tua seconda domanda parte

Quante colonne possono essere utilizzati insieme come una chiave primaria in una determinata tabella?

è specifico dell'implementazione: è definito nel DBMS effettivo utilizzato. [1], [2], [3] È necessario controllare le specifiche tecniche del sistema di database che si utilizza. Alcuni sono molto dettagliati, altri no. La ricerca sul Web di questa limitazione può essere difficile perché la terminologia varia. Il termine primario composito chiave si dovrebbe rendere obbligatorio;)

Se non è possibile trovare informazioni esplicite, provare con un database di test per garantire la si può aspettare stabile (e specifico) la gestione di violazione dei limiti (che sono ragionevolmente aspettarsi). Fai attenzione a ottenere le giuste informazioni a riguardo: a volte i limiti vengono accumulati e vedrai risultati diversi con diversi layout di database.