Se aderisci a Zero, One or Many principio, per cui o non esiste una cosa del genere, una di queste, o un numero illimitato, costruiresti sempre tabelle correttamente normalizzate per tenere traccia di cose come questa.
Ad esempio, un possibile schema:
CREATE TABLE user_attributes (
id INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
user_id INT NOT NULL,
attribute_name VARCHAR(255) NOT NULL,
attribute_value VARCHAR(255),
UNIQUE INDEX index_user_attributes_name(user_id, attribute_name)
);
Questo è il modello di base del negozio valore-chiave in cui puoi averne molti attributi per utente.
Sebbene i requisiti di archiviazione per questo siano superiori a un accordo a colonne fisse con nomi perennemente frustranti come attribute1 , il costo è abbastanza basso nell'era dei dischi rigidi da terabyte che raramente è un problema.
In genere creeresti una singola tabella per questi dati fino a quando il tempo di inserimento non diventa un problema. Finché i tuoi inserti sono veloci, non me ne preoccuperei. A quel punto dovresti prendere in considerazione un sharding strategia per dividere questi dati in più tabelle con uno schema identico, ma solo se necessario.
Immagino che sarebbe nella fase di ~ 10-50 milioni di righe, ma potrebbe essere maggiore se la quantità di attività di inserimento in questa tabella è relativamente bassa.
Non dimenticare che il modo migliore per ottimizzare l'attività di lettura è utilizzare una cache:la query del database più veloce è quella che non esegui. Per questo genere di cose di solito usi qualcosa come memcached per memorizzare i risultati dei recuperi precedenti e lo invalideresti in una scrittura.
Come sempre, confronta qualsiasi schema proposto in produzione scala.
