La regola d'oro per la progettazione del software: dipende.
Il problema di provare a valutarlo nel modo in cui lo stai facendo è che non ci sono informazioni sufficienti. Quello che ho visto funziona bene è quello di concentrarmi solo su un buon design normalizzato ( link ) e utilizzare indici appropriati per le prestazioni, quindi de-normalizzare come ultima risorsa in caso di problemi di prestazioni.
Ad esempio, il nostro DBA ha rilevato che dopo aver ridimensionato la nostra app dopo un decennio, un sacco del tempo del database è stato speso JOIN ing in tabelle aggiuntive solo per ottenere una singola colonna. Duplicare un paio di colonne chiave in un paio di tabelle (penso che abbia usato un trigger per mantenerlo, ma non è sicuro, non era la mia area) per eliminare un po 'di JOIN s usato frequentemente ha aiutato a migliorare le prestazioni. Non è stato un grosso problema, ma immagina che il 90% delle tue domande abbia ottenuto il 10% più velocemente. Potrebbe valerne la pena.
Ancora una volta, questo è stato dopo 10 anni di osservazione e ottimizzazione. Non saltare in questo tipo di ottimizzazione. Concentrati sulla normalizzazione finché non trovi un valido motivo per de-normalizzare.
Questo trade-off che stai cercando è troppo caso per caso. Non esiste un numero massimo specifico di colonne che posso dire che sono troppe.