Cose da considerare con i tuoi approcci
Memorizzazione del profilo utente nella tabella Utenti
- Questo sarà generalmente l'approccio più veloce in termini di ottenere i dati del profilo, anche se potresti avere molti dati ridondanti qui (colonne che potrebbero non contenere alcuna informazione).
- Veloce (soprattutto se estrai solo le colonne che ti servono dal db)
- Dati sprecati
- Più difficile lavorare con/mantenere (probabilmente con interfacce come PHPMyAdmin)
Memorizzazione del profilo utente nella relazione User_Profile Tabella 1-1 con gli utenti
- Dovrebbe essere comunque abbastanza veloce con un join e potresti eliminare un po' di ridondanza dei dati se i profili utente non vengono creati a meno che un utente non ne riempia uno.
- Più facile da lavorare
- Sempre leggermente più lento a causa dell'adesione (o della seconda query)
Memorizzazione del profilo utente come proprietà e valori nelle tabelle
*cioè. Tabella per memorizzare le possibili opzioni, tabella per memorizzare user_id, option_id e valore*
- Nessun dato ridondante memorizzato, tutti i dati sono rilevanti
- Metodo più normalizzato
- Recupero e aggiornamento dei dati più lenti
La mia impressione è che la maggior parte dei siti Web utilizzi il 2° metodo e memorizzi le informazioni del profilo in una seconda tabella, è comune per la maggior parte dei siti Web più grandi denormalizzare il database (twitter, facebook) per ottenere prestazioni di lettura maggiori a scapito di prestazioni di scrittura più lente.
Penserei che mantenere le informazioni del profilo in una seconda tabella sia probabilmente la strada da percorrere quando si esaminano 50.000 record. Per ottenere prestazioni ottimali, desideri mantenere i dati scritti pesantemente separati dai dati di lettura pesante per garantire che la cache possa funzionare in modo efficiente.
