Una tabella di database dovrebbe sempre avere le chiavi primarie?

Question

Devo sempre avere una chiave primaria nelle tabelle del mio database?

Prendiamo la codifica SO. Puoi vedere il tag in qualsiasi revisione, è probabile che si trovi in ??una tabella tag_rev con il postID e il numero di revisione. Avrei bisogno di un PK per questo?

Anche dal momento che è in una tabella rev e che attualmente non utilizza i tag dovrebbe essere un BLOB di tagID invece di più voci di più coppie tagid post_id?

Answer 1

Dovresti cercare di avere una chiave primaria in qualsiasi tabella non banale in cui è probabile che tu voglia accedere (o aggiornare o eliminare) singoli record da quella chiave. Le chiavi primarie possono essere composte da più colonne e, formalmente parlando, sarà la superkey più breve disponibile; vale a dire, il gruppo di colonne disponibile più breve che, insieme, identifica in modo univoco qualsiasi riga.

Non so come sia lo schema del database Stack Overflow (e da alcune delle cose che ho letto sul blog di Jeff, non voglio), ma nella situazione che descrivi, è del tutto possibile lì è una chiave primaria attraverso l'identificatore di post, il numero di revisione e il valore del tag; certamente, sarebbe il superkey più breve (e unico) disponibile.

Per quanto riguarda il tuo secondo punto, mentre può essere ragionevole argomentare a favore dell'aggregazione dei valori nelle tabelle di archivio, va contro il principio che ogni intersezione di riga / colonna in una tabella dovrebbe contenere un singolo valore. Sebbene possa semplificare leggermente lo sviluppo, non vi è alcun motivo per cui non è possibile mantenere una tabella normalizzata con metadati con versione, anche per qualcosa di così banale come i tag.

Answer 2

Una tabella dovrebbe avere una chiave primaria in modo da poter identificare ciascuna riga in modo univoco con essa.

Tecnicamente, puoi avere tabelle senza una chiave primaria, ma infrangerai le buone regole di progettazione del database.

Answer 3

Tendo a concordare sul fatto che la maggior parte delle tabelle dovrebbe avere una chiave primaria. Posso solo pensare a due volte in cui non ha senso farlo.

1. Se si dispone di una tabella che collega le chiavi ad altre chiavi. Ad esempio, per mettere in relazione un id_utente con un answer_id, quella tabella non avrebbe bisogno di una chiave primaria.
2. Una tabella di registrazione, il cui unico scopo reale è creare una pista di controllo.

Fondamentalmente, se stai scrivendo una tabella che potrebbe mai aver bisogno di essere referenziata in una relazione di chiave esterna, allora una chiave primaria è importante, e se non puoi essere positivo non lo sarà, quindi aggiungi il PK. :)

Answer 4

Vedi questa domanda correlata sulla necessità di una chiave primaria intera . Una delle risposte usa il tagging come esempio:

Ci sono buoni motivi per avere una tabella di database senza una chiave primaria intera

Per ulteriori discussioni su tag e chiavi, vedi questa domanda:

ID per tag nei sistemi di tag

Answer 5

Dalla sezione del manuale di riferimento di MySQL 5.5 13.1.17 :

  

Se non si dispone di un PRIMARY KEY e un'applicazione richiede il PRIMARY KEY nelle tabelle, MySQL restituisce il primo indice UNIQUE che non ha colonne NULL come PRIMARY KEY.

Quindi, tecnicamente, la risposta è no. Tuttavia, come altri hanno affermato, nella maggior parte dei casi è abbastanza utile.

Answer 6

Credo fermamente che ogni tabella dovrebbe avere un modo per identificare in modo univoco un record. Per il 99% delle tabelle, questa è una chiave primaria. Per il resto potresti cavartela con un indice univoco (penso che una colonna cerchi le tabelle dei tipi qui). Ogni volta che ho dovuto lavorare con una tabella senza un modo per identificare in modo univoco i record, ci sono stati problemi.

Credo anche che se stai usando chiavi surrogate come PK, dovresti, ove possibile, avere un indice univoco separato su qualunque combinazione di campi costituisca la chiave naturale. Mi rendo conto che ci sono troppe volte in cui non hai una vera chiave naturale (i nomi non sono univoci o ciò che rende qualcosa di unico potrebbe essere distribuito su più tabelle parentchild), ma se ne hai uno, per favore assicurati per favore ha un indice univoco o viene creato come PK.

Answer 7

Se non è presente alcun PK, come si aggiorna o elimina una singola riga? Sarebbe impossibile! Ad essere sincero, ho usato alcune tabelle delle volte senza PK, ad esempio per memorizzare i registri delle attività, ma anche in questo caso è consigliabile averne uno perché i timestamp non potrebbero essere abbastanza granulari. Le tabelle temporanee sono un altro esempio. Ma secondo la teoria relazionale il PK è obbligatorio.

Answer 8

è bene avere chiavi e relazioni. Aiuta molto tuttavia se la tua app è abbastanza buona da gestire le relazioni, potresti eventualmente saltare le chiavi (anche se ti consiglio di averle)

Answer 9

Poiché utilizzo Subsonic, creo sempre una chiave primaria per tutte le mie tabelle. Molte librerie di DB Abstraction richiedono una chiave primaria per funzionare.

Nota: ciò non risponde alla "Grande teoria unificata" tono della tua domanda, ma sto solo dicendo che in pratica, a volte DEVI creare una chiave primaria per ogni tabella.

Answer 10

Se si tratta di una tabella di join, non direi che hai bisogno di una chiave primaria. Supponiamo, ad esempio, di avere tabelle PERSONS, SICKPEOPLE e ILLNESSES. La tabella ILLNESSES ha cose come influenza, raffreddore, ecc., Ognuna con una chiave primaria. PERSONS ha le solite cose sulle persone, ognuna anche con una chiave primaria. La tabella SICKPEOPLE contiene solo persone malate e ha due colonne, PERSONID e ILLNESSID, chiavi esterne nelle rispettive tabelle e nessuna chiave primaria. Le tabelle PERSONS e ILLNESSES contengono entità e le entità ottengono le chiavi primarie. Le voci nella tabella SICKPEOPLE non sono entità e non ottengono chiavi primarie.

Answer 11

I database non hanno chiavi di per sé, ma le loro tabelle costituenti potrebbero. Presumo tu intenda questo, ma per ogni evenienza ...

Comunque, le tabelle con un gran numero di righe dovrebbero assolutamente avere chiavi primarie; le tabelle con solo poche righe non ne hanno necessariamente bisogno, anche se non fanno male. Dipende dall'uso e dalle dimensioni della tabella. I puristi inseriranno le chiavi primarie in ogni tabella. Questo non è sbagliato; e nessuno dei due omette PK in tabelle di piccole dimensioni.

Modificato per aggiungere un collegamento al mio post di blog su questa domanda, in cui discuto un caso in cui il personale dell'amministrazione del database non ha ritenuto necessario includere una chiave primaria in una particolare tabella. Penso che ciò illustri adeguatamente il mio punto.

Blog di Cyberherbalist Pubblica su chiavi primarie