Als u zich houdt aan de Zero, One of Many principe, waarbij er ofwel niet zoiets is, een van hen, of een onbeperkt aantal, je zou altijd goed genormaliseerde tabellen bouwen om dit soort dingen bij te houden.
Bijvoorbeeld een mogelijk 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)
);
Dit is het basispatroon voor sleutel/waarde-winkels waar u veel . kunt hebben attributen per gebruiker.
Hoewel de opslagvereisten hiervoor hoger zijn dan een arrangement met vaste kolommen met de eeuwig frustrerende namen zoals attribute1 , zijn de kosten in het tijdperk van harde schijven van terabyte zo klein dat het zelden een probleem is.
Over het algemeen maakt u een enkele tabel voor deze gegevens totdat de invoegtijd een probleem wordt. Zolang je inserts snel zijn, zou ik me er geen zorgen over maken. Op dat moment zou je een sharding willen overwegen strategie om deze gegevens in meerdere tabellen met een identiek schema te verdelen, maar alleen als dat nodig is.
Ik kan me voorstellen dat dit in het stadium van ~ 10-50 miljoen rijen zou zijn, maar het zou hoger kunnen zijn als de hoeveelheid invoegactiviteit in deze tabel relatief laag is.
Vergeet niet dat de beste manier om te optimaliseren voor leesactiviteit is om een cache te gebruiken:de snelste databasequery is degene die u niet maakt. Voor dat soort dingen gebruik je meestal iets als memcached om de resultaten van eerdere ophaalacties op te slaan, en u zou dit ongeldig maken door te schrijven.
Vergelijk zoals altijd elk voorgesteld schema bij productie schaal.