Comme d'habitude - cela dépend.
Tout d'abord, il existe un nombre maximum de colonnes que MySQL peut soutien , et vous n'avez pas vraiment envie d'y arriver.
Deuxièmement, il y a un impact sur les performances lors de l'insertion ou de la mise à jour si vous avez beaucoup de colonnes avec un index (bien que je ne sois pas sûr que cela ait de l'importance sur le matériel moderne).
Troisièmement, les grandes tables sont souvent un dépotoir pour toutes les données qui semblent liées à l'entité principale ; cela rend rapidement la conception floue. Par exemple, la conception que vous présentez montre 3 champs de type "statut" différents (statut, is_admin et fb_account_verified) - je soupçonne qu'il existe une logique métier qui devrait les lier (un administrateur doit être un utilisateur vérifié, par exemple), mais votre la conception ne supporte pas cela.
Cela peut ou non être un problème - c'est plus une question conceptuelle, d'architecture/conception qu'une question de performance/va-t-il fonctionner. Cependant, dans de tels cas, vous pouvez envisager de créer des tableaux pour refléter les informations associées sur le compte, même s'il n'y a pas de relation x-à-plusieurs. Ainsi, vous pouvez créer "user_profile", "user_credentials", "user_fb", "user_activity", tous liés par user_id. bout de tableau. Cependant, cela ne rendra pas votre base de données plus rapide ou plus évolutive. Le coût des joints est susceptible d'être négligeable.
Quoi que vous fassiez, l'option 2 - sérialiser les "champs rarement utilisés" dans un seul champ de texte - est une idée terrible. Vous ne pouvez pas valider les données (les dates peuvent donc être invalides, les nombres peuvent être du texte, des valeurs non nulles peuvent être manquantes) et toute utilisation dans une clause "where" devient très lente.
Une alternative populaire est les magasins "Entité/Attribut/Valeur" ou "Clé/Valeur". Cette solution présente certains avantages - vous pouvez stocker vos données dans une base de données relationnelle même si votre schéma change ou est inconnu au moment de la conception. Cependant, ils présentent également des inconvénients :il est difficile de valider les données au niveau de la base de données (type de données et nullabilité), il est difficile de créer des liens significatifs vers d'autres tables à l'aide de relations de clé étrangère, et interroger les données peut devenir très compliqué - imaginez trouver tous enregistrements où le statut est 1 et le facebook_id est nul et la date d'enregistrement est supérieure à hier.
Étant donné que vous semblez connaître le schéma de vos données, je dirais que "clé/valeur" n'est pas un bon choix.
