Sembra che tu sappia già la risposta, ma ricorda, mantieni i sistemi che progetti semplici da modificare poiché i modelli di business cambiano sempre nel tempo o alla fine falliscono (è una generalizzazione ma hai l'idea). Un corollario di ciò è se crei un modello rigido, veloce o lento, è rigido, le modifiche saranno più difficili e l'utente finale non vedrà la differenza, quindi non si ottiene alcun cambiamento di denaro/felicità, a meno che non sia un cambiamento molto negativo. Il tuo problema non è tecnico nel modo in cui una query funziona sul motore, ma più filosofico, cambiamenti facili rispetto alla velocità apparente. Chiediti, qual è il vantaggio di avere un database normalizzato? Pensa a un'architettura e un design puliti, le prestazioni sono il problema minore nel mondo di oggi poiché l'elaborazione è più economica e anche lo storage. Ma il design è costoso. La normalizzazione è stata fatta per realizzare sistemi che non dipendono da decisioni dell'ultimo momento ma da un processo di progettazione strutturato. I tavoli grandi non sono un grosso problema per MySql ma sono un grosso problema da mantenere, modificare ed espandere. Non si tratta solo di aggiungere un'altra colonna, si tratta della struttura rigida dei dati stessi. Alla fine aggiungerai semplicemente colonne che contengono indici e quegli indici punteranno a piccole tabelle. MySql cercherà comunque di aggirare tutti quei dati. Quindi sceglierò il primo, molti tavolini, molti-a-molti.
