Non è necessario includere il nome dell'elemento in entrambe le tabelle. Questa è chiamata una soluzione denormalizzata. Dovresti averlo solo nella tabella degli elementi e fare riferimento solo all'id, quindi se hai bisogno del nome puoi anche unirlo in base alla chiave primaria (id). Altrimenti è totalmente OK nel mio parere.
CREATE TABLE user(
id INT(11) NOT NULL AUTO_INCREMENT,
username VARCHAR(50) NOT NULL,
password VARCHAR(20) NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE items(
i_id INT(11) NOT NULL AUTO_INCREMENT,
name TINYTEXT NOT NULL,
price DECIMAL(8,2) NOT NULL,
PRIMARY KEY (i_id)
);
CREATE TABLE user_purchase(
i_id INT(11) NOT NULL,
name TINYTEXT NOT NULL,
id INT(11) NOT NULL,
FOREIGN KEY (i_id) REFERENCES items(i_id),
FOREIGN KEY (id) REFERENCES user(id)
);
A volte, quando le prestazioni sono critiche, è necessario utilizzare tabelle denormalizzate. Può essere molto più veloce.
La normalizzazione è importante per evitare diverse anomalie. Se hai tabelle in una forma normale di alto livello, le tue tabelle non saranno ridondanti e non avranno queste anomalie. Ad esempio, se hai qualcosa archiviato in più posizioni, devi occuparti di mantenere aggiornati tutti i dati ridondanti. Questo ti dà la possibilità di farlo in modo errato e finire per avere diverse anomalie.
Nella tua situazione avere una chiave esterna ti aiuta a mantenere l'integrità dei dati ma senza una chiave esterna per il nome potresti avere articoli con nomi negli acquisti che non sono presenti nella tabella articoli.
Questa è una specie di anomalia.
Ci sono molti tipi di questo, meglio evitarli il più a lungo possibile.
Leggi di più qui sulle anomalie
In alcuni casi è necessario denomalizzare. Quindi archivia alcuni dati in modo ridondante a causa di problemi di prestazioni. In questo modo puoi risparmiare alcune operazioni di join che potrebbero richiedere molto tempo.
I dettagli della normalizzazione sono trattati da argomenti di diverse forme normali:NF0, NF1, NF2, NF3 e BCNF
Per ulteriori dettagli sui fondamenti matematici della decomposizione senza perdita di dati in forme normali superiori, vedere "Dipendenze funzionali". Questo ti aiuterà a capire perché puoi mantenere gli ID "ridondanti". Praticamente sono ridondanza necessaria, poiché ne hai bisogno per poter ricostruire in seguito il set di dati originale. Questa sarà la definizione per le diverse forme normali. Quale livello di ridondanza è consentito?
