Jeśli zastosujesz się do Zera, Jednego lub Wielu Zasada, zgodnie z którą albo nie ma czegoś takiego, albo nie ma jednej z nich, albo nieograniczona liczba, zawsze budujesz odpowiednio znormalizowane tabele, aby śledzić takie rzeczy.
Na przykład możliwy schemat:
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)
);
To jest podstawowy wzorzec sklepu klucz-wartość, w którym możesz mieć wiele atrybuty na użytkownika.
Chociaż wymagania dotyczące przechowywania są wyższe niż w przypadku stałych kolumn z wiecznie frustrującymi nazwami, takimi jak attribute1 , koszt jest na tyle niski w dobie dysków twardych o wielkości terabajtów, że rzadko stanowi problem.
Zwykle tworzysz jedną tabelę dla tych danych, dopóki czas wstawienia nie stanie się problemem. Dopóki twoje wstawki są szybkie, nie przejmowałbym się tym. W tym momencie warto rozważyć sharding strategia podzielenia tych danych na wiele tabel o identycznym schemacie, ale tylko wtedy, gdy jest to wymagane.
Wyobrażam sobie, że byłoby to na etapie ~10-50 milionów wierszy, ale mogłoby być wyższe, gdyby ilość aktywności wstawiania w tej tabeli była stosunkowo niska.
Nie zapominaj, że najlepszym sposobem optymalizacji pod kątem odczytu jest użycie pamięci podręcznej:Najszybsze zapytanie do bazy danych to takie, którego nie wykonujesz. Do tego typu rzeczy zwykle używasz czegoś takiego jak memcached do przechowywania wyników poprzednich pobrań i unieważniłbyś to podczas zapisu.
Jak zawsze, porównaj każdy proponowany schemat w produkcji skala.
