Het lijkt erop dat u het antwoord al weet, maar onthoud:houd de systemen die u ontwerpt eenvoudig aan te passen, aangezien bedrijfsmodellen in de loop van de tijd altijd veranderen of ze uiteindelijk mislukken (het is een generalisatie, maar u snapt het idee). Een uitvloeisel daarvan is dat als je een rigide model maakt, snel of langzaam, het rigide is, veranderingen moeilijker zullen zijn en de eindgebruiker het verschil niet zal zien, dus er wordt geen verandering in geld/geluk bereikt, tenzij het een zeer slechte verandering is. Uw probleem is niet technisch in een manier waarop een query op de engine werkt, maar meer een filosofisch probleem, gemakkelijke veranderingen versus schijnbare snelheid. Stel uzelf de vraag, wat is het voordeel van een genormaliseerde database? Denk aan een schone architectuur en design, prestatie is het minste probleem in de wereld van vandaag, aangezien verwerking goedkoper is en opslag ook. Maar ontwerp is duur. Normalisatie is gemaakt om systemen te maken die niet afhankelijk zijn van beslissingen op het laatste moment, maar van een gestructureerd ontwerpproces. Grote tabellen zijn geen big deal voor MySql, maar ze zijn een big deal om te onderhouden, aan te passen en uit te breiden. Het gaat niet alleen om het toevoegen van nog een kolom, het gaat om de rigide structuur van de gegevens zelf. Uiteindelijk zul je na verloop van tijd alleen kolommen toevoegen die indexen bevatten, en die indexen zullen naar kleine tabellen verwijzen. MySql zal zich hoe dan ook een weg banen door al die gegevens. Dus ik ga voor de eerste, veel kleine tabellen, veel-op-veel.
