Jako obvykle - záleží.
Za prvé, existuje maximální počet sloupců, které může MySQL podpora a ve skutečnosti se tam nechcete dostat.
Za druhé, pokud máte mnoho sloupců s indexem, má to vliv na výkon při vkládání nebo aktualizaci (i když si nejsem jistý, jestli na moderním hardwaru na tom záleží).
Za třetí, velké tabulky jsou často skládkou pro všechna data, která se zdají souviset s hlavní entitou; to rychle činí design nejasným. Například návrh, který prezentujete, zobrazuje 3 různá pole typu „stav“ (status, is_admin a fb_account_verified) – mám podezření, že existuje nějaká obchodní logika, která by je měla propojit (například správce musí být ověřeným uživatelem), ale váš design to nepodporuje.
To může, ale nemusí být problém – je to spíše koncepční, architektonická/designová otázka než otázka výkonu/bude to fungovat. V takových případech však můžete zvážit vytvoření tabulek, které budou odrážet související informace o účtu, i když nemá vztah x-to-many. Můžete tedy vytvořit "user_profile", "user_credentials", "user_fb", "user_activity", vše propojené pomocí user_id. Díky tomu je přehlednější a pokud musíte přidat další pole související s facebookem, nebudou se motat na konec stolu. Vaše databáze však nebude rychlejší ani škálovatelnější. Náklady na spojení budou pravděpodobně zanedbatelné.
Ať uděláte cokoli, možnost 2 – serializace „zřídka používaných polí“ do jednoho textového pole – je hrozný nápad. Nemůžete ověřit data (takže data mohou být neplatná, čísla mohou být text, ne-null mohou chybět) a jakékoli použití v klauzuli „where“ je velmi pomalé.
Oblíbenou alternativou jsou obchody „Entity/Atribute/Value“ nebo „Key/Value“. Toto řešení má některé výhody – svá data můžete ukládat do relační databáze, i když se vaše schéma změní nebo je v době návrhu neznámé. Mají však také své nevýhody:je obtížné ověřit data na úrovni databáze (datový typ a možnost null), je obtížné vytvořit smysluplné odkazy na jiné tabulky pomocí vztahů cizích klíčů a dotazování na data může být velmi komplikované - představte si, že najdete všechny záznamy, kde je stav 1 a facebook_id je null a datum registrace je vyšší než včera.
Vzhledem k tomu, že se zdá, že znáte schéma svých dat, řekl bych, že „klíč/hodnota“ není dobrá volba.