Mysql :flera bord eller ett stort bord?

Om du följer Noll, en eller många princip, där det antingen inte finns något sådant, en av dem, eller ett obegränsat antal, skulle du alltid bygga korrekt normaliserade tabeller för att spåra saker som detta.

Till exempel ett möjligt 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)
);

Detta är det grundläggande nyckel-värde-lagringsmönstret där du kan ha många attribut per användare.

Även om lagringskraven för detta är högre än ett arrangemang med fasta kolumner med de evigt frustrerande namnen som attribute1 , kostnaden är tillräckligt liten i en ålder av terabytestora hårddiskar att det sällan är ett problem.

I allmänhet skulle du skapa en enda tabell för dessa data tills insättningstiden blir ett problem. Så länge dina insatser är snabba skulle jag inte oroa mig för det. Då skulle du vilja överväga en sharding strategi för att dela upp denna data i flera tabeller med ett identiskt schema, men bara om det krävs.

Jag kan föreställa mig att det skulle vara på ~10-50 miljoner rader, men kan vara högre om mängden infogningsaktivitet i den här tabellen är relativt låg.

Glöm inte att det bästa sättet att optimera för läsaktivitet är att använda en cache:Den snabbaste databasfrågan är den du inte gör. För den sortens saker använder du vanligtvis något som memcached för att lagra resultaten från tidigare hämtningar, och du skulle ogiltigförklara detta vid en skrivning.

Som alltid, jämför alla föreslagna scheman vid produktion skala.