Zoals gewoonlijk - het hangt ervan af.
Ten eerste is er een maximaal aantal kolommen dat MySQL kan ondersteuning , en je wilt er niet echt komen.
Ten tweede is er een prestatie-impact bij het invoegen of bijwerken als je veel kolommen met een index hebt (hoewel ik niet zeker weet of dit van belang is op moderne hardware).
Ten derde zijn grote tabellen vaak een stortplaats voor alle gegevens die verband lijken te houden met de kernentiteit; dit maakt het ontwerp al snel onduidelijk. Het ontwerp dat u presenteert, toont bijvoorbeeld 3 verschillende velden van het type "status" (status, is_admin en fb_account_verified) - ik vermoed dat er een zakelijke logica is die deze aan elkaar moet koppelen (een beheerder moet bijvoorbeeld een geverifieerde gebruiker zijn), maar uw ontwerp ondersteunt dat niet.
Dit kan al dan niet een probleem zijn - het is meer een conceptuele, architectuur / ontwerpvraag dan een prestatie / zal het werken. In dergelijke gevallen kunt u echter overwegen tabellen te maken om de gerelateerde informatie over de rekening weer te geven, zelfs als deze geen x-op-veel-relatie heeft. U kunt dus "user_profile", "user_credentials", "user_fb", "user_activity" maken, allemaal gekoppeld door user_id. Dit maakt het netter, en als u meer Facebook-gerelateerde velden moet toevoegen, bungelen ze niet aan de einde van de tafel. Het zal uw database echter niet sneller of schaalbaarder maken. De kosten van de verbindingen zijn waarschijnlijk te verwaarlozen.
Wat je ook doet, optie 2 - het serialiseren van "zelden gebruikte velden" in een enkel tekstveld - is een slecht idee. U kunt de gegevens niet valideren (dus datums kunnen ongeldig zijn, getallen kunnen tekst zijn, niet-nulls kunnen ontbreken), en elk gebruik in een "waar"-clausule wordt erg traag.
Een populair alternatief is "Entity/Attribute/Value" of "Sleutel/Value" stores. Deze oplossing heeft enkele voordelen:u kunt uw gegevens opslaan in een relationele database, zelfs als uw schema verandert of op het moment van ontwerpen onbekend is. Ze hebben echter ook nadelen:het is moeilijk om de gegevens op databaseniveau te valideren (gegevenstype en nullabiliteit), het is moeilijk om zinvolle koppelingen te maken naar andere tabellen met behulp van externe sleutelrelaties, en het opvragen van de gegevens kan erg ingewikkeld worden - stel je voor dat je alle records waarbij de status 1 is en de facebook_id null is en de registratiedatum groter is dan gisteren.
Aangezien u het schema van uw gegevens lijkt te kennen, zou ik zeggen dat "sleutel/waarde" geen goede keuze is.