Hvis du overholder Nul, en eller mange princip, hvorved der enten ikke er sådan noget, en af dem eller et ubegrænset antal, ville du altid bygge korrekt normaliserede tabeller for at spore ting som dette.
For eksempel et muligt skema:
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)
);
Dette er det grundlæggende nøgleværdi-lagermønster, hvor du kan have mange attributter pr. bruger.
Selvom lagerkravene til dette er højere end et arrangement med faste kolonner med de evigt frustrerende navne som attribute1 , omkostningerne er små nok i en alder af terabyte-store harddiske, at det sjældent er et problem.
Generelt vil du oprette en enkelt tabel for disse data, indtil indsættelsestiden bliver et problem. Så længe dine indsatser er hurtige, ville jeg ikke bekymre mig om det. På det tidspunkt vil du overveje en sharding strategi til at opdele disse data i flere tabeller med et identisk skema, men kun hvis det er påkrævet.
Jeg kunne forestille mig, at det ville være på ~10-50 millioner rækker stadiet, men kunne være højere, hvis mængden af indsatsaktivitet i denne tabel er relativt lav.
Glem ikke, at den bedste måde at optimere til læseaktivitet på er at bruge en cache:Den hurtigste databaseforespørgsel er den, du ikke laver. Til den slags bruger du normalt noget som memcached for at gemme resultaterne af tidligere hentning, og du ville ugyldiggøre dette ved en skrivning.
Som altid, benchmark ethvert foreslået skema ved produktion skala.