mysql - tabelle - Una tabella di database può essere senza una chiave primaria?




primary key e foreign key (8)

Qualcuno può dirmi se una tabella in un database relazionale (come MySQL / SQL SERVER) può essere senza una chiave primaria?

Ad esempio, potrei avere tabella day_temperature , dove registro la temperature e il time . Non vedo il motivo per avere una chiave primaria per un tale tavolo.


Come sempre dipende

La tabella non deve avere la chiave primaria. Molto più importante è avere indici corretti . Sul motore del database dipende da come la chiave primaria influisce sugli indici (ad esempio crea un indice univoco per la colonna / le colonne della chiave primaria).

Tuttavia, nel tuo caso (e nel 99% anche in altri casi), aggiungerei una nuova colonna unica di incremento automatico come temp_id e renderla surrogata chiave primaria.

Rende molto più facile mantenere questo tavolo - per esempio trovare e rimuovere record (cioè record duplicati) - e credimi - per ogni tabella arriva il momento di sistemare le cose :(.


Ho un esempio migliore di una tabella che non ha bisogno di una chiave primaria - una tabella di falegnameria. Diciamo che ho una tabella con qualcosa chiamato "capability", e un'altra tabella con qualcosa chiamata "groups", e voglio una tabella di joiner che mi dica tutte le funzionalità che potrebbero avere tutti i gruppi, quindi è fondamentalmente

create table capability_group
(  capability_id varchar(32),
    group_id     varchar(32));

Non c'è motivo di avere una chiave primaria su questo, perché non si indirizza mai una singola riga: si desidera che tutte le funzionalità per un dato gruppo o tutti i gruppi per una determinata capacità. Sarebbe meglio avere un vincolo univoco su (capabilty_id, group_id) e indici separati su entrambi i campi.


Includerei una chiave surrogata / auto-incremento, specialmente se esiste la possibilità di letture di tempi / temperature duplicati. Non avresti altro modo per identificare in modo univoco una riga duplicata.


La chiave primaria non sarebbe naturalmente l'ora? avresti mai avuto più di una temperatura per un dato tempo?

Una domanda migliore da porsi sarebbe: "Perché dovresti mai creare un tavolo senza una chiave primaria"


Non hai bisogno di un PK, ma è consigliabile averne uno. È il modo migliore per identificare le righe univoche. A volte non vuoi un PK incrementale automatico int, ma piuttosto crea il PK su qualcos'altro. Ad esempio, nel tuo caso, se c'è una sola riga per volta, devi creare il PK sul tempo. Rende le ricerche basate sul tempo più veloce, in più assicura che siano uniche (puoi essere certo che l'integrità dei dati non è violata):


Quando si replica un database su mysql, una tabella senza una chiave primaria potrebbe causare ritardi nella replica.

http://lists.mysql.com/mysql/227217

L'errore più comune quando si utilizza ROW o MIXED è l'impossibilità di verificare che ogni tabella che si desidera replicare abbia una CHIAVE PRIMARIA su di essa. Questo è un errore perché quando un evento ROW (come quello documentato sopra) viene inviato allo slave e né la copia del master né la copia dello slave della tabella ha una PRIMARY KEY sul tavolo, non c'è modo di identificare facilmente quale riga univoca che si desidera che la replica cambi.


Secondo la tua risposta, prenderei in considerazione tre opzioni:

  • metti un PK su entrambe le colonne, in questo modo ogni volta potrebbe esserci solo una temp e viceversa. Questa soluzione consente più righe con la stessa temperatura o lo stesso tempo solo per cui non ci sarebbero due righe con lo stesso tempo E TEM.
  • non mettere un PK a tutti, ma mettere un indice univoco su entrambe le colonne. un unico indice contenente entrambi i colori. ciò consentirebbe null in temp e tempo ma incorre in più spazio per mantenere l'indice.

queste due opzioni sono le migliori per la velocità di recupero se si hanno letture pesanti, ma si otterrebbe una frequenza di inserimenti inferiore, in quanto anche gli indici dovrebbero essere aggiornati.

  • non inserire alcun indice, né PK. questo sarebbe meglio per gli inserti, ma molto brutto per la ricerca. utile per la registrazione in cui il recupero viene eseguito da un altro meccanismo o quando non è necessario inserire il dispositivo per verificare la presenza di duplicati.

Inoltre, è molto importante considerare la cardinalità qui e pensare alle conseguenze future dell'uso di un numero incrementale automatico. se hai intenzione di fare MOLTI inserti, anche un bigint senza auto incrementato automatico potrebbe essere un rischio perché alla fine si esaurirebbe. Nel tuo esempio, immagino che salverai i dati ogni giorno - per quanto tempo? questo sarebbe problematico se si salvasse temp ogni minuto ... quindi considererò questo come un esempio estremo.

Immagino sia meglio pensare a quello che ti serve dal tavolo. stai facendo "salva-e-dimentica" per l'intero anno per la temperatura ogni minuto? hai intenzione di utilizzare questa tabella frequentemente nel processo decisionale in tempo reale nella tua logica aziendale? Penso che sia meglio separare i dati necessari per il real-time (oltp) dai dati di salvataggio a lungo termine che sarebbero richiesti di rado e la sua latenza di recupero può essere elevata (olap). vale anche la duplicazione dei dati in due tabelle diverse, una pesantemente indicizzata e cancellata una volta ogni tanto per controllare la cardinalità e la seconda è effettivamente salvata su un disco magentic con quasi nessun indice (è possibile trasferire uno schema dal proprio fs principale in un'altra fs).


Tecnicamente, puoi dichiarare tale tabella.

Ma nel tuo caso, il time dovrebbe essere fatto il PRIMARY KEY , dal momento che probabilmente è sbagliato avere temperature diverse per lo stesso tempo e probabilmente inutile avere lo stesso più di una volta.

Logicamente, ogni tabella dovrebbe avere una PRIMARY KEY modo da poter distinguere due record.

Se non hai una chiave candidata nei tuoi dati, creane una sostitutiva ( AUTO_INCREMENT , SERIAL o qualsiasi altra cosa il tuo database offra).

L'unica scusa per non avere un PRIMARY KEY è un log o una tabella simile che è soggetta a un DML pesante e avere un indice su di esso inciderà sulle prestazioni oltre il livello di tolleranza.







database