Както обикновено - зависи.
Първо, има максимален брой колони, които MySQL може поддръжка и всъщност не искате да стигнете до там.
Второ, има въздействие върху производителността при вмъкване или актуализиране, ако имате много колони с индекс (макар че не съм сигурен дали това има значение при съвременния хардуер).
Трето, големите таблици често са сметище за всички данни, които изглеждат свързани с основния обект; това бързо прави дизайна неясен. Например, дизайнът, който представяте, показва 3 различни полета тип "статус" (статус, is_admin и fb_account_verified) - подозирам, че има някаква бизнес логика, която трябва да ги свърже заедно (администраторът трябва да е потвърден потребител, например), но вашият дизайнът не поддържа това.
Това може или не може да е проблем - това е по-скоро концептуален, архитектурен/дизайнерски въпрос, отколкото въпрос за изпълнение/ще работи ли. В такива случаи обаче можете да помислите за създаване на таблици, които да отразяват свързаната информация за акаунта, дори ако той няма връзка x-към-много. Така че можете да създадете „user_profile“, „user_credentials“, „user_fb“, „user_activity“, всички свързани от user_id. Това го прави по-изчистен и ако трябва да добавите повече полета, свързани с facebook, те няма да висят на край на масата. Това обаче няма да направи вашата база данни по-бърза или по-мащабируема. Цената на присъединяванията вероятно ще бъде незначителна.
Каквото и да правите, вариант 2 - сериализиране на "рядко използвани полета" в едно текстово поле - е ужасна идея. Не можете да потвърдите данните (така че датите може да са невалидни, числата може да са текст, не-нули може да липсват) и всяко използване в клауза „къде“ става много бавно.
Популярна алтернатива е магазините "Entity/Attribute/Value" или "Key/Value". Това решение има някои предимства - можете да съхранявате вашите данни в релационна база данни, дори ако вашата схема се промени или е неизвестна по време на проектиране. Те обаче имат и недостатъци:трудно е да се валидират данните на ниво база данни (тип на данните и възможност за нищожност), трудно е да се направят смислени връзки към други таблици, използвайки релации на външен ключ, и запитването на данните може да стане много сложно - представете си да намерите всички записи, при които състоянието е 1 и facebook_id е нула и датата на регистрация е по-голяма от вчера.
Като се има предвид, че изглежда знаете схемата на вашите данни, бих казал, че „ключ/стойност“ не е добър избор.
