Ако се придържате към нула, едно или много принцип, при който или няма такова нещо, едно от тях, или неограничен брой, винаги бихте изградили правилно нормализирани таблици, за да проследявате неща като това.
Например възможна схема:
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)
);
Това е основният модел на магазин ключ-стойност, където можете да имате много атрибути на потребител.
Въпреки че изискванията за съхранение за това са по-високи от подредбата с фиксирани колони с постоянно разочароващи имена като attribute1
, цената е достатъчно малка в ерата на твърдите дискове с размер на терабайти, че рядко е проблем.
Обикновено създавате една таблица за тези данни, докато времето за вмъкване не стане проблем. Докато вашите вмъквания са бързи, няма да се притеснявам за това. В този момент бихте искали да помислите за разчленяване стратегия за разделяне на тези данни на множество таблици с идентична схема, но само ако е необходимо.
Предполагам, че това ще бъде на етап от ~10-50 милиона реда, но може да бъде по-високо, ако количеството активност на вмъкване в тази таблица е сравнително ниско.
Не забравяйте, че най-добрият начин за оптимизиране за четене е да използвате кеш:Най-бързата заявка към базата данни е тази, която не правите. За такива неща обикновено използвате нещо като memcached за да съхраните резултатите от предишните извличания и бихте обезсилили това при запис.
Както винаги, сравни всяка предложена схема в производство мащаб.