Si se adhiere a Cero, Uno o Muchos principio, por el cual no existe tal cosa, uno de ellos, o un número ilimitado, siempre construiría tablas correctamente normalizadas para rastrear cosas como esta.
Por ejemplo, un posible esquema:
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)
);
Este es el patrón básico de almacenamiento de clave-valor donde puede tener muchos atributos por usuario.
Aunque los requisitos de almacenamiento para esto son más altos que un arreglo de columnas fijas con nombres perpetuamente frustrantes como attribute1 , el costo es lo suficientemente pequeño en la era de los discos duros de terabytes como para que rara vez sea un problema.
En general, crearía una sola tabla para estos datos hasta que el tiempo de inserción se convierta en un problema. Siempre que sus inserciones sean rápidas, no me preocuparía. En ese momento, querrá considerar un fragmentación estrategia para dividir estos datos en varias tablas con un esquema idéntico, pero solo si es necesario.
Me imagino que estaría en la etapa de ~10-50 millones de filas, pero podría ser mayor si la cantidad de actividad de inserción en esta tabla es relativamente baja.
No olvides que la mejor manera de optimizar la actividad de lectura es usar un caché:la consulta de base de datos más rápida es la que no haces. Para ese tipo de cosas, normalmente empleas algo como memcached para almacenar los resultados de búsquedas anteriores, y lo invalidarías en una escritura.
Como siempre, compare cualquier esquema propuesto en producción escala.
