Alcuni punti:
Sembra che tu stia solo usando ciò che è attualmente unico nella tabella e lo stai rendendo come chiave primaria. Che funzioni. E le chiavi naturali presentano alcuni vantaggi quando si tratta di eseguire query a causa della località. (I dati di ogni utente sono memorizzati nella stessa area). E poiché la tabella è raggruppata da quella chiave che elimina le ricerche nei dati se stai cercando in base alle colonne nel primario.
-
Tuttavia, l'utilizzo di una chiave primaria naturale come quella che hai scelto presenta degli svantaggi anche in termini di prestazioni.
-
L'uso di una chiave primaria molto grande renderà tutti gli altri indici molto grandi in innodb perché la chiave primaria è inclusa in ogni valore di indice.
-
L'uso di una chiave primaria naturale non è veloce come una chiave surrogata per INSERT perché oltre ad essere più grande non può semplicemente inserirsi alla fine della tabella ogni volta. Deve essere inserito nella sezione per quell'utente e postare ecc.
-
Inoltre, se stai cercando in base al tempo, molto probabilmente cercherai in tutta la tabella con una chiave naturale a meno che il tempo non sia la tua prima colonna. le chiavi surrogate tendono ad essere locali per tempo e spesso possono essere giuste per alcune query.
-
Anche l'utilizzo di una chiave naturale come la tua come chiave primaria può essere fastidioso. E se si desidera fare riferimento a un voto particolare? Hai bisogno di alcuni campi. Inoltre è un po' difficile da usare con molti ORM.
Ecco la risposta
Creerei la tua chiave surrogata e la userei come chiave primaria piuttosto che fare affidamento sulla chiave primaria interna di innodb perché sarai in grado di usarla per aggiornamenti e ricerche.
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
Ma, se crei una chiave primaria surrogata, renderei anche la tua chiave UNICA. Stesso costo ma impone la correttezza.
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );
