Wydaje się, że znasz już odpowiedź, ale pamiętaj, aby projektowane przez siebie systemy były łatwe do modyfikacji, ponieważ modele biznesowe zawsze zmieniają się w czasie lub w końcu zawodzą (to uogólnienie, ale masz pomysł). Konsekwencją tego jest to, że jeśli zrobisz sztywny model, szybki lub wolny, jest on sztywny, zmiany będą trudniejsze, a użytkownik końcowy nie zauważy różnicy, stąd nie można osiągnąć żadnej zmiany ceny/szczęścia, chyba że jest to bardzo zła zmiana. Twój problem nie ma charakteru technicznego w sposób, w jaki zapytanie działa na silniku, ale bardziej filozoficzny, łatwe zmiany w porównaniu z pozorną szybkością. Zadaj sobie pytanie, jaka jest zaleta posiadania znormalizowanej bazy danych? Pomyśl o czystej architekturze i projekcie, wydajność jest najmniejszym problemem w dzisiejszym świecie, ponieważ przetwarzanie jest tańsze, a także przechowywanie. Ale projektowanie jest drogie. Normalizacja została dokonana, aby stworzyć systemy, które nie zależą od decyzji podejmowanych w ostatniej chwili, ale od ustrukturyzowanego procesu projektowania. Duże tabele nie są wielkim problemem dla MySql, ale wymagają ich utrzymania, modyfikacji i rozbudowy. Nie chodzi tylko o dodanie jeszcze jednej kolumny, chodzi o sztywną strukturę samych danych. W końcu z czasem po prostu dodasz kolumny zawierające indeksy, a te indeksy będą wskazywać na małe tabele. MySql i tak będzie omijać wszystkie te dane. Pójdę więc do pierwszego, wielu małych tabelek, wiele do wielu.
