Come al solito, dipende.
Innanzitutto, esiste un numero massimo di colonne che MySQL può supporto , e non vuoi davvero arrivarci.
In secondo luogo, c'è un impatto sulle prestazioni durante l'inserimento o l'aggiornamento se hai molte colonne con un indice (anche se non sono sicuro che questo sia importante sull'hardware moderno).
In terzo luogo, le tabelle di grandi dimensioni sono spesso una discarica per tutti i dati che sembrano correlati all'entità principale; questo rende rapidamente il design poco chiaro. Ad esempio, il design che presenti mostra 3 diversi campi di tipo "stato" (status, is_admin e fb_account_verified) - Sospetto che ci sia una logica aziendale che dovrebbe collegarli insieme (un amministratore deve essere un utente verificato, ad esempio), ma il tuo il design non lo supporta.
Questo può essere o meno un problema:è più una questione concettuale, di architettura/design che di prestazioni/funzionerà. Tuttavia, in questi casi, potresti prendere in considerazione la creazione di tabelle per riflettere le informazioni correlate sull'account, anche se non ha una relazione x-a-molti. Quindi, potresti creare "user_profile", "user_credentials", "user_fb", "user_activity", tutti collegati da user_id. Questo lo rende più ordinato e se devi aggiungere più campi relativi a Facebook, non penzolano al fine della tavola. Tuttavia, non renderà il tuo database più veloce o più scalabile. È probabile che il costo dei join sia irrisorio.
Qualunque cosa tu faccia, l'opzione 2 - serializzare "campi usati raramente" in un unico campo di testo - è un'idea terribile. Non è possibile convalidare i dati (quindi le date potrebbero non essere valide, i numeri potrebbero essere testo, i non-null potrebbero mancare) e qualsiasi utilizzo in una clausola "where" diventa molto lento.
Un'alternativa popolare sono i negozi "Entità/Attributo/Valore" o "Chiave/Valore". Questa soluzione presenta alcuni vantaggi:puoi archiviare i tuoi dati in un database relazionale anche se lo schema cambia o è sconosciuto in fase di progettazione. Tuttavia, hanno anche degli svantaggi:è difficile convalidare i dati a livello di database (tipo di dati e capacità di annullamento), è difficile creare collegamenti significativi ad altre tabelle utilizzando relazioni di chiave esterna e interrogare i dati può diventare molto complicato:immagina di trovare tutto record in cui lo stato è 1 e facebook_id è nullo e la data di registrazione è maggiore di ieri.
Dato che sembri conoscere lo schema dei tuoi dati, direi che "chiave/valore" non è una buona scelta.
