Pokud dodržujete nula, jedna nebo mnoho princip, podle kterého buď žádná taková věc neexistuje, jedna z nich, nebo neomezený počet, vždy byste vytvořili správně normalizované tabulky pro sledování věcí, jako je tato.
Například možné schéma:
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)
);
Toto je základní vzor úložiště párů klíč–hodnota, kde jich můžete mít mnoho atributy na uživatele.
Ačkoli požadavky na úložiště jsou vyšší než u uspořádání s pevnými sloupci s neustále frustrujícími názvy jako attribute1
, náklady jsou ve věku pevných disků o velikosti terabajtů dostatečně nízké, takže to není problém.
Obecně byste pro tato data vytvořili jednu tabulku, dokud se čas vložení nestane problémem. Pokud jsou vaše vložky rychlé, nebál bych se toho. V tomto okamžiku byste měli zvážit sharding strategii rozdělit tato data do více tabulek se stejným schématem, ale pouze v případě, že je to vyžadováno.
Představoval bych si, že by to bylo ve fázi ~10–50 milionů řádků, ale mohlo by to být vyšší, pokud je množství aktivity vkládání v této tabulce relativně nízké.
Nezapomeňte, že nejlepším způsobem optimalizace pro činnost čtení je použití mezipaměti:Nejrychlejší databázový dotaz je ten, který neprovedete. Pro takové věci obvykle používáte něco jako memcached uložit výsledky předchozích načtení a při zápisu byste to zrušili.
Jako vždy porovnejte jakékoli navrhované schéma při výrobě měřítko.