Como de costumbre, depende.
En primer lugar, hay un número máximo de columnas que MySQL puede apoyo , y realmente no quieres llegar allí.
En segundo lugar, hay un impacto en el rendimiento al insertar o actualizar si tiene muchas columnas con un índice (aunque no estoy seguro de si esto es importante en el hardware moderno).
En tercer lugar, las tablas grandes suelen ser un basurero para todos los datos que parecen estar relacionados con la entidad central; esto rápidamente hace que el diseño no sea claro. Por ejemplo, el diseño que presenta muestra 3 campos de tipo de "estado" diferentes (estado, is_admin y fb_account_verified). Sospecho que hay alguna lógica comercial que debería vincularlos (un administrador debe ser un usuario verificado, por ejemplo), pero su el diseño no soporta eso.
Esto puede o no ser un problema:es más una cuestión conceptual de arquitectura/diseño que una cuestión de rendimiento/funcionará. Sin embargo, en tales casos, puede considerar crear tablas para reflejar la información relacionada con la cuenta, incluso si no tiene una relación de x a muchos. Por lo tanto, puede crear "perfil_usuario", "credenciales_usuario", "fb_usuario", "actividad_usuario", todos vinculados por id_usuario. Esto lo hace más ordenado, y si tiene que agregar más campos relacionados con Facebook, no colgarán en el final de la mesa. Sin embargo, no hará que su base de datos sea más rápida o más escalable. Es probable que el costo de las uniones sea insignificante.
Hagas lo que hagas, la opción 2, serializar "campos raramente usados" en un solo campo de texto, es una idea terrible. No puede validar los datos (por lo que las fechas pueden no ser válidas, los números pueden ser texto, pueden faltar valores no nulos) y cualquier uso en una cláusula "dónde" se vuelve muy lento.
Una alternativa popular son las tiendas "Entidad/Atributo/Valor" o "Clave/Valor". Esta solución tiene algunos beneficios:puede almacenar sus datos en una base de datos relacional incluso si su esquema cambia o es desconocido en el momento del diseño. Sin embargo, también tienen inconvenientes:es difícil validar los datos en el nivel de la base de datos (tipo de datos y nulabilidad), es difícil hacer enlaces significativos a otras tablas utilizando relaciones de clave externa, y consultar los datos puede volverse muy complicado; imagine encontrar todos registros donde el estado es 1 y el facebook_id es nulo y la fecha de registro es posterior a ayer.
Dado que parece conocer el esquema de sus datos, diría que "clave/valor" no es una buena opción.
