Devo usare chiavi primarie a più colonne o aggiungere una nuova colonna?

Il mio attuale progetto di database utilizza una chiave primaria a più colonne per utilizzare i dati esistenti (che sarebbero comunque unici) invece di creare una colonna aggiuntiva che assegna a ciascuna voce una chiave arbitraria. So che questo è permesso, ma mi chiedevo se questa è una pratica che potrei voler usare con cautela ed eventualmente evitare (proprio come andare in C).

Quindi quali sono alcuni degli svantaggi che potrei vedere in questo approccio o perché potrei volere una chiave a colonna singola?

Di solito, quando si dispone di una tabella con una chiave primaria multi-colonna, è il risultato di una tabella di join (molti-a-molti) che diventa elevata come propria entità (e quindi merita la propria chiave primaria). Ci sono molti che sostengono che qualsiasi tabella di join DOVREBBE essere un'entità per impostazione predefinita, ma questa è una discussione per un altro giorno.

Diamo un'occhiata a un'ipotetica relazione da molte a molte:

Studente * --- * Classe

(uno studente può essere in più classi, una classe può avere più studenti).

Tra queste due tabelle ci sarà una tabella di giunzione chiamata StudentClass (o ClassStudent a seconda di come la scrivi). A volte, vuoi tenere traccia di cose come quando lo studente era in classe. Quindi lo aggiungerai alla tabella StudentClass. A questo punto, StudentClass è diventato un'entità unica ... e dovrebbe essere assegnato un nome per riconoscerlo come tale, ad esempio Iscrizione.

Studente 1 --- * Iscrizione * --- 1 lezione

(uno studente può avere molte iscrizioni, ogni iscrizione è per una classe (o andando nel modo opposto una classe può avere molte iscrizioni, ogni iscrizione è per uno studente).

Ora puoi fare domande su quanti studenti sono stati iscritti alla classe Chemistry 101 l'anno scorso? O in quali classi era iscritto lo studente John Doe mentre frequentava la Acme University? Ciò era possibile senza la chiave primaria separata, ma una volta che si dispone di una chiave primaria per l'iscrizione, una domanda più semplice sarebbe di queste iscrizioni (per ID), quanti studenti hanno ricevuto un voto di passaggio?

La determinazione del fatto che un'entità meriti un PK si riduce a quanta query (o manipolazione) farai per quell'entità. Diciamo ad esempio che volevi allegare i compiti completati per uno studente in una classe. Il luogo logico in cui allegare questa entità (Assegnazione) sarebbe sull'entità Iscrizione. Dare la registrazione alla propria chiave primaria renderebbe più semplici le query di assegnazione.

Ha senso avere una colonna id separata. Quando vuoi ottenere qualcosa dalla tabella del tuo database, è più facile fare:

SELECT whatever FROM table WHERE id=13

di SELEZIONA qualunque cosa DALLA tabella DOVE col1 = 'val1' AND col2 = 'val2' AND col3 = 'val3'

Ad esempio, in un'applicazione Web si traduce in un URL simile al seguente:

www.somewebsite.com/somepage.php?id=13

o in questo modo:

www.somewebsite.com/somepage.php?col1=val1&col2=val2&col3=val3

Fondamentalmente ti stai chiedendo se dovresti usare chiavi surrogate o naturali (nel tuo caso suona come chiavi naturali composite ). Ecco un ottimo articolo: http://www.agiledata.org/essays/keys.html

Preferisco le chiavi surrogate perché semplificano l'amministrazione durante la vita del DB (non devi mai preoccuparti dell'implicazione delle chiavi che cambiano significato, cosa che non dovrebbe mai accadere ma succede in qualsiasi sistema reale in cui sono coinvolti gli umani). Tuttavia , se nel DB sono presenti molte tabelle di "ricerca" (ovvero tabelle che sono sostanzialmente chiavi: coppie di valori), le chiavi surrogate possono risultare ingombranti perché è necessario unire quelle tabelle alla query per ottenere risultati significativi.

Ad esempio, supponiamo che tu abbia due entità: Indirizzo e Paese.

• La relazione è: Indirizzo * ----- 1 Paese
• L'entità Paese è fondamentalmente una chiave: coppia di valori (ad es. USA: Stati Uniti, CA: Canada, MX: Messico, ecc ...)
• Per eseguire una query su questa struttura per tutti gli indirizzi negli Stati Uniti:

select * from Address where CountryCode = 'US'

• Per eseguire la stessa query con chiavi surrogate:

select Address.* from Address join Country on Address.CountryID = Country.ID where Country.Code = 'US'

Mi sento a mio agio a imporre chiavi naturali per le tabelle di ricerca e chiavi surrogate per tutto il resto, se sono abbastanza sicuro che le chiavi naturali non cambieranno troppo spesso, se mai.

Dipende da come accedi ai dati. Se esegui molte ricerche di chiavi parziali (in cui selezioni i record in base ad esempio solo due delle tre chiavi), ti consigliamo di conservare le chiavi multiparte. OTOH, se hai molte relazioni 1: 1 con altre tabelle, probabilmente ha più senso avere una chiave surrogata.

Mi piace avere sempre una chiave primaria surrogata per ogni tabella. Ma non ci sono molte ragioni "difficili" per far valere ciò che ho sentito.

L'unica volta che ho mai avuto una chiave naturale multi-colonna mi ha morso è stato con ORM. Occasionalmente avrei problemi con una chiave primaria a più colonne usando Linq To Entities.

Non dire mai mai, ma unirsi su 4 colonne è un dolore. Più colonne hai con dati intelligenti, maggiori sono le possibilità che questi valori possano cambiare. I database possono essere configurati per mantenere l'integrità referenziale con aggiornamenti a cascata.

Puoi sempre creare un altro indice per gestire i valori univoci.

Le prestazioni sono probabilmente trascurabili nella maggior parte dei casi, ma è possibile testare le query con e senza la chiave surragate.

Trovo difficile trovare una buona ragione per imporre una chiave separata, ma come hai detto molte persone lo inseriscono.

Non trovo questo di aiuto (specialmente con l'archiviazione) quando si tratta di tabelle dei fatti / dettagli. L'esempio canonico una tabella dei fatti di vendita con (customer_key, store_key, product_key) con quantità non ha molto senso avere una chiave a livello di record.

Avere PK come autoincremento aumenta la seccatura se scopri che la tua chiave composita può effettivamente avere dei duplicati.

C'è una buona discussione che risale al 2002 su Ask Tom . È specifico per Oracle, ma la discussione più ampia è rilevante qualunque sia il database in uso.