Si vous adhérez au zéro, un ou plusieurs principe, selon lequel il n'y a rien de tel, l'un d'entre eux, ou un nombre illimité, vous construiriez toujours des tables correctement normalisées pour suivre des choses comme celle-ci.
Par exemple, un schéma possible :
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)
);
Il s'agit du modèle de base du magasin clé-valeur où vous pouvez en avoir plusieurs attributs par utilisateur.
Bien que les exigences de stockage pour cela soient plus élevées qu'un arrangement à colonnes fixes avec des noms perpétuellement frustrants comme attribute1 , le coût est suffisamment faible à l'ère des disques durs de la taille d'un téraoctet pour que ce soit rarement un problème.
Généralement, vous créez une seule table pour ces données jusqu'à ce que le temps d'insertion devienne un problème. Tant que vos insertions sont rapides, je ne m'en soucierais pas. À ce stade, vous voudriez envisager un sharding stratégie pour diviser ces données en plusieurs tables avec un schéma identique, mais seulement si cela est nécessaire.
J'imagine que ce serait au stade d'environ 10 à 50 millions de lignes, mais cela pourrait être plus élevé si la quantité d'activité d'insertion dans ce tableau est relativement faible.
N'oubliez pas que la meilleure façon d'optimiser l'activité de lecture est d'utiliser un cache :la requête de base de données la plus rapide est celle que vous ne faites pas. Pour ce genre de chose, vous utilisez généralement quelque chose comme memcached pour stocker les résultats des récupérations précédentes, et vous l'invaliderez lors d'une écriture.
Comme toujours, comparez tout schéma proposé en production échelle.
