Wie immer - es kommt darauf an.
Erstens gibt es eine maximale Anzahl von Spalten, die MySQL verwenden kann unterstützen , und Sie möchten nicht wirklich dorthin gelangen.
Zweitens wirkt sich das Einfügen oder Aktualisieren auf die Leistung aus, wenn Sie viele Spalten mit einem Index haben (obwohl ich nicht sicher bin, ob dies auf moderner Hardware von Bedeutung ist).
Drittens sind große Tabellen oft eine Müllhalde für alle Daten, die sich auf die Kernentität beziehen; dies macht das Design schnell unübersichtlich. Das von Ihnen präsentierte Design zeigt beispielsweise 3 verschiedene Felder vom Typ "Status" (status, is_admin und fb_account_verified) - ich vermute, dass es eine Geschäftslogik gibt, die diese miteinander verknüpfen sollte (ein Administrator muss beispielsweise ein verifizierter Benutzer sein), aber Ihre Design unterstützt das nicht.
Dies kann ein Problem sein oder auch nicht - es ist eher eine konzeptionelle, Architektur-/Designfrage als eine Frage der Leistung/Wird es funktionieren. In solchen Fällen können Sie jedoch erwägen, Tabellen zu erstellen, um die zugehörigen Informationen über das Konto widerzuspiegeln, selbst wenn es keine x-zu-viele-Beziehung gibt. Sie könnten also „user_profile“, „user_credentials“, „user_fb“, „user_activity“ erstellen, die alle durch user_id verknüpft sind. Dies macht es übersichtlicher, und wenn Sie weitere Facebook-bezogene Felder hinzufügen müssen, werden sie nicht baumeln Ende der Tabelle. Es wird Ihre Datenbank jedoch nicht schneller oder skalierbarer machen. Die Kosten für die Verbindungen sind wahrscheinlich vernachlässigbar.
Was auch immer Sie tun, Option 2 – „selten verwendete Felder“ in ein einzelnes Textfeld zu serialisieren – ist eine schreckliche Idee. Sie können die Daten nicht validieren (daher könnten Datumsangaben ungültig sein, Zahlen könnten Text sein, Nicht-Nullen könnten fehlen), und jede Verwendung in einer „where“-Klausel wird sehr langsam.
Eine beliebte Alternative sind "Entity/Attribute/Value"- oder "Key/Value"-Stores. Diese Lösung hat einige Vorteile:Sie können Ihre Daten in einer relationalen Datenbank speichern, selbst wenn sich Ihr Schema ändert oder zur Entwurfszeit unbekannt ist. Sie haben jedoch auch Nachteile:Es ist schwierig, die Daten auf Datenbankebene zu validieren (Datentyp und Nullzulässigkeit), es ist schwierig, mithilfe von Fremdschlüsselbeziehungen aussagekräftige Verknüpfungen zu anderen Tabellen herzustellen, und das Abfragen der Daten kann sehr kompliziert werden – stellen Sie sich vor, alle zu finden Datensätze, bei denen der Status 1 ist und die facebook_id null ist und das Registrierungsdatum größer als gestern ist.
Angesichts der Tatsache, dass Sie das Schema Ihrer Daten zu kennen scheinen, würde ich sagen, dass "Schlüssel/Wert" keine gute Wahl ist.
