Jak zwykle – to zależy.
Po pierwsze, istnieje maksymalna liczba kolumn, które MySQL może wsparcie i tak naprawdę nie chcesz się tam dostać.
Po drugie, wstawianie lub aktualizowanie ma wpływ na wydajność, jeśli masz wiele kolumn z indeksem (choć nie jestem pewien, czy ma to znaczenie na nowoczesnym sprzęcie).
Po trzecie, duże tabele są często miejscem zrzutu wszystkich danych, które wydają się być powiązane z głównym podmiotem; to szybko czyni projekt niejasnym. Na przykład prezentowany projekt pokazuje 3 różne pola typu „status” (status, is_admin i fb_account_verified) — podejrzewam, że istnieje jakaś logika biznesowa, która powinna je połączyć (administrator musi być na przykład zweryfikowanym użytkownikiem), ale twój projekt tego nie obsługuje.
Może to być problem, ale nie musi - to bardziej kwestia konceptualna, architektura/projektowanie niż wydajność/czy to zadziała. Jednak w takich przypadkach można rozważyć utworzenie tabel, aby odzwierciedlić powiązane informacje o koncie, nawet jeśli nie ma relacji x-do-wielu. Możesz więc utworzyć „user_profile”, „user_credentials”, „user_fb”, „user_activity”, wszystkie połączone przez user_id. To sprawia, że jest ładniejszy, a jeśli musisz dodać więcej pól związanych z facebookiem, nie będą zwisać na koniec tabeli. Nie sprawi to jednak, że Twoja baza danych będzie szybsza ani bardziej skalowalna. Koszt złączeń będzie prawdopodobnie znikomy.
Cokolwiek robisz, opcja 2 – serializacja „rzadko używanych pól” w jedno pole tekstowe – to fatalny pomysł. Nie można zweryfikować danych (więc daty mogą być nieprawidłowe, liczby mogą być tekstem, może brakować wartości not-null), a każde użycie w klauzuli "where" staje się bardzo powolne.
Popularną alternatywą są sklepy typu „Jednostka/Atrybut/Wartość” lub „Klucz/Wartość”. To rozwiązanie ma pewne zalety — możesz przechowywać dane w relacyjnej bazie danych, nawet jeśli Twój schemat ulegnie zmianie lub jest nieznany w czasie projektowania. Mają jednak również wady:trudno jest zweryfikować dane na poziomie bazy danych (typ danych i dopuszczalność wartości null), trudno tworzyć sensowne linki do innych tabel przy użyciu relacji klucza obcego, a zapytania o dane mogą stać się bardzo skomplikowane – wyobraź sobie znalezienie wszystkich rekordy, w których status wynosi 1, a facebook_id jest pusty, a data rejestracji jest większa niż wczoraj.
Biorąc pod uwagę, że wydajesz się znać schemat swoich danych, powiedziałbym, że „klucz/wartość” nie jest dobrym wyborem.
