Chiave primaria composta o no?

Ecco cosa mi sta confondendo. Ho spesso chiavi primarie composite nelle tabelle del database. Il lato negativo di questo approccio è che ho un bel lavoro extra quando elimino o modifichi le voci. Tuttavia, ritengo che questo approccio sia nello spirito del design del database.

Dall’altro lato, ci sono miei amici, che non usano mai le chiavi composite, ma piuttosto introducono un’altra colonna ‘id’ in una tabella, e tutte le altre chiavi sono solo FK. Hanno molto meno lavoro durante la codifica delle procedure di cancellazione e modifica. Tuttavia, non so come preservino l’unicità delle voci di dati.

Per esempio:
Modo 1

create table ProxUsingDept ( fkProx int references Prox(ProxID) NOT NULL, fkDept int references Department(DeptID) NOT NULL, Value int, PRIMARY KEY(fkProx,fkDept) ) 

Via 2

 create table ProxUsingDept ( ID int NOT NULL IDENTITY PRIMARY KEY fkProx int references Prox(ProxID) NOT NULL, fkDept int references Department(DeptID) NOT NULL, Value int ) 

Qual è il modo migliore? Quali sono i lati negativi dell’utilizzo del secondo approccio? Eventuali suggerimenti?

Personalmente preferisco il tuo secondo approccio (e lo userei quasi il 100% delle volte) – introdurre un campo ID surrogato.

Perché?

  • rende la vita molto più semplice per tutte le tabelle che fanno riferimento alla tua tabella: le condizioni JOIN sono molto più semplici con una sola colonna ID (piuttosto che 2, 3 o anche più colonne a cui devi partecipare, sempre)

  • rende la vita molto più semplice poiché ogni tabella che fa riferimento al tuo tavolo ha solo bisogno di portare un singolo ID come campo chiave esterna – non più colonne dalla tua chiave composta

  • rende la vita molto più semplice poiché il database può gestire la creazione di una colonna ID univoca (usando INT IDENTITY )

Tuttavia, non so come preservino l’unicità delle voci di dati.

Molto semplice: metti un INDICE UNICO sulle colonne composte che altrimenti utilizzeresti come chiave primaria!

 CREATE UNIQUE INDEX UIX_WhateverNameYouWant ON dbo.ProxUsingDept(fkProx, fkDept) 

Ora, il tuo tavolo garantisce che non ci sarà mai una coppia di duplicati (fkProx, fkDept) nella tua tabella – problema risolto!

Tu fai le seguenti domande:

Tuttavia, non so come preservino l’unicità delle voci di dati.

L’unicità può essere preservata dichiarando un indice UNIQUE composito separato su colonne che altrimenti formsrebbero la chiave primaria naturale.

Qual è il modo migliore?

Persone diverse hanno opinioni diverse, a volte fortemente sostenute. Penso che scoprirete che più persone usano le chiavi intere surrogate (non ciò che rende la soluzione “giusta”).

Quali sono i lati negativi dell’utilizzo del secondo approccio?

Ecco alcuni degli svantaggi dell’utilizzo di una chiave surrogata:

  1. È necessario un indice aggiuntivo per mantenere l’unicità della chiave primaria naturale.

  2. A volte devi richiedere JOIN aggiuntivi quando selezioni i dati per ottenere i risultati desiderati (ciò accade quando puoi soddisfare i requisiti della query utilizzando solo le colonne nella chiave naturale composta, in questo caso puoi utilizzare le colonne chiave esterna anziché JOINing torna alla tabella originale).

Ci sono casi come M: N join tabelle in cui le chiavi composite hanno più senso (e se la natura o il link M: N cambia, dovrai comunque rielaborare questa tabella).

So che è passato molto tempo da quando è stato realizzato questo post. Ma ho dovuto imbattersi in una situazione simile per quanto riguarda la chiave composita, quindi sto postando i miei pensieri.

Diciamo che abbiamo due tabelle T1 e T2.

T1 ha le colonne C1 e C2.

T2 ha le colonne C1, C2 e C3

C1 e C2 sono le chiavi primarie composte per la tabella T1 e le chiavi esterne per la tabella T2.

Supponiamo di aver usato una chiave surrogata per la tabella T1 (T1_ID) e l’abbiamo usata come chiave esterna nella tabella T2, se i valori di C1 e C2 della tabella T1 cambiano, è un lavoro aggiuntivo per far rispettare il vincolo di ingestività referenziale sul tabella T2 poiché stiamo cercando solo la chiave surrogata dalla tabella T1 il cui valore non è cambiato nella tabella T1. Questo potrebbe essere un problema con il secondo approccio.