Zaktualizowano 4 czerwca 2017
Biorąc pod uwagę, że to pytanie/odpowiedź zyskały pewną popularność, uznałem, że warto je zaktualizować.
Kiedy to pytanie zostało pierwotnie opublikowane, MySQL nie obsługiwał typów danych JSON, a obsługa PostgreSQL była w powijakach. Od wersji 5.7 MySQL obsługuje teraz typ danych JSON (w formacie binarnym) i PostgreSQL JSONB znacznie dojrzał. Oba produkty zapewniają wydajne typy JSON, które mogą przechowywać dowolne dokumenty, w tym obsługę indeksowania określonych kluczy obiektu JSON.
Jednak nadal stoję przy moim pierwotnym stwierdzeniu, że domyślną preferencją podczas korzystania z relacyjnej bazy danych powinna być nadal kolumna na wartość. Relacyjne bazy danych nadal budowane są przy założeniu, że dane w nich zawarte będą dość dobrze znormalizowane. Planer zapytań ma lepsze informacje dotyczące optymalizacji podczas przeglądania kolumn niż podczas przeglądania kluczy w dokumencie JSON. Klucze obce można tworzyć między kolumnami (ale nie między kluczami w dokumentach JSON). Co ważne:jeśli większość twojego schematu jest wystarczająco niestabilna, aby uzasadnić użycie JSON, możesz przynajmniej rozważyć, czy relacyjna baza danych jest właściwym wyborem.
To powiedziawszy, niewiele aplikacji jest idealnie relacyjnych lub zorientowanych na dokumenty. Większość aplikacji zawiera mieszankę obu. Oto kilka przykładów, w których osobiście uważam, że JSON jest przydatny w relacyjnej bazie danych:
-
Podczas przechowywania adresów e-mail i numerów telefonów dla kontaktu, gdy przechowywanie ich jako wartości w tablicy JSON jest znacznie łatwiejsze niż zarządzanie wieloma oddzielnymi tabelami
-
Zapisywanie dowolnych preferencji użytkownika klucza/wartości (gdzie wartość może być logiczna, tekstowa lub numeryczna, a nie chcesz mieć oddzielnych kolumn dla różnych typów danych)
-
Przechowywanie danych konfiguracyjnych, które nie mają zdefiniowanego schematu (jeśli budujesz Zapier lub IFTTT i musisz przechowywać dane konfiguracyjne dla każdej integracji)
Jestem pewien, że są też inne, ale to tylko kilka szybkich przykładów.
Oryginalna odpowiedź
Jeśli naprawdę chcesz mieć możliwość dodawania tylu pól, ile chcesz, bez ograniczeń (poza arbitralnym limitem rozmiaru dokumentu), rozważ rozwiązanie NoSQL, takie jak MongoDB.
W przypadku relacyjnych baz danych:użyj jednej kolumny na wartość. Umieszczenie obiektu blob JSON w kolumnie praktycznie uniemożliwia wykonywanie zapytań (i boleśnie powolne, gdy faktycznie znajdziesz zapytanie, które działa).
Relacyjne bazy danych wykorzystują typy danych podczas indeksowania i są przeznaczone do implementacji z znormalizowanym struktura.
Na marginesie:nie oznacza to, że nigdy nie powinieneś przechowywać JSON w relacyjnej bazie danych. Jeśli dodajesz prawdziwe metadane lub jeśli Twój JSON opisuje informacje, których nie trzeba pytać i jest używany tylko do wyświetlania, tworzenie oddzielnej kolumny dla wszystkich punktów danych może być przesadą.
