Wenn Sie sich an die Null, Eins oder Viele halten Prinzip, bei dem es entweder keinen oder einen davon gibt, oder eine unbegrenzte Anzahl, würden Sie immer richtig normalisierte Tabellen erstellen, um solche Dinge zu verfolgen.
Zum Beispiel ein mögliches 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)
);
Dies ist das grundlegende Schlüsselwertspeichermuster, bei dem Sie viele haben können Attribute pro Benutzer.
Allerdings ist der Speicherbedarf dafür höher als bei einer festen Spaltenanordnung mit den immer wieder frustrierenden Namen wie attribute1 , sind die Kosten im Zeitalter von Festplatten im Terabyte-Bereich so gering, dass sie selten ein Problem darstellen.
Im Allgemeinen würden Sie eine einzelne Tabelle für diese Daten erstellen, bis die Einfügezeit zu einem Problem wird. Solange Ihre Einsätze schnell sind, würde ich mir darüber keine Sorgen machen. An diesem Punkt sollten Sie ein Sharding in Betracht ziehen Strategie, diese Daten in mehrere Tabellen mit identischem Schema aufzuteilen, aber nur, wenn es erforderlich ist.
Ich würde mir vorstellen, dass das etwa 10–50 Millionen Zeilen beträgt, aber es könnte höher sein, wenn die Menge an Einfügeaktivitäten in dieser Tabelle relativ gering ist.
Vergessen Sie nicht, dass der beste Weg zur Optimierung der Leseaktivität die Verwendung eines Caches ist:Die schnellste Datenbankabfrage ist die, die Sie nicht durchführen. Für solche Dinge verwenden Sie normalerweise etwas wie memcached um die Ergebnisse früherer Abrufe zu speichern, und Sie würden dies bei einem Schreibvorgang ungültig machen.
Vergleichen Sie wie immer jedes vorgeschlagene Schema in der Produktion Maßstab.
