Typy danych JSON (przechowywane jako NVARCHAR)

Dane JSON są przechowywane jako NVARCHAR, a ich strukturę weryfikują dedykowane funkcje SQL Server.

JSON w SQL Server: format dokumentu w kolumnie tekstowej

JSON, czyli JavaScript Object Notation, opisuje dane jako obiekty z parami „nazwa–wartość” oraz tablice uporządkowanych elementów. W SQL Server dokument JSON może znajdować się w kolumnie typu NVARCHAR, ponieważ silnik traktuje go jako tekst Unicode. Nie powstaje przy tym osobny typ kolumny przechowujący strukturę dokumentu tak, jak w niektórych bazach dokumentowych. Za odczytywanie pól, sprawdzanie poprawności i modyfikowanie zawartości odpowiadają funkcje przeznaczone do pracy z JSON.

Tekstowa reprezentacja pozwala przechowywać w jednym polu dane o zmiennej liczbie właściwości. Przykładowy dokument może opisywać konfigurację programu, parametry urządzenia, wynik operacji albo dodatkowe atrybuty rekordu. Poszczególne dokumenty w tej samej kolumnie mogą zawierać różne klucze, ale taka elastyczność nie usuwa potrzeby kontrolowania formatu. Aplikacja i baza powinny uzgodnić nazwy właściwości, ich typy logiczne, dopuszczalne wartości oraz sposób oznaczania braku danych.

Do podstawowej kontroli składni służy funkcja ISJSON. Można wykorzystać ją w zapytaniu kontrolnym, warunku walidacji albo ograniczeniu CHECK, aby odrzucać tekst, który nie jest poprawnym dokumentem JSON. Sama poprawność składni nie oznacza jednak, że dokument ma właściwe znaczenie biznesowe. JSON z poprawnie zapisanym kluczem może nadal zawierać nieprawidłowy zakres wartości, nieoczekiwany typ albo brak wymaganej właściwości.

Ważną cechą NVARCHAR jest zachowanie znaków Unicode, co ma znaczenie przy nazwach, opisach i danych w języku polskim. Rozmiar kolumny powinien odpowiadać przewidywanej wielkości dokumentów. Zbyt mała długość prowadzi do odrzucania danych lub ich obcięcia na wcześniejszym etapie przetwarzania, natomiast bardzo szeroka kolumna może utrudniać ocenę kosztu przechowywania i indeksowania.

Odczyt pól, tablic i danych relacyjnych

SQL Server udostępnia kilka sposobów odczytywania wartości z dokumentu. JSON_VALUE służy do pobierania pojedynczej wartości skalarnej, takiej jak tekst, liczba, wartość logiczna lub informacja o identyfikatorze. JSON_QUERY jest przeznaczona do pobierania obiektu albo tablicy jako fragmentu JSON. Różnica jest istotna: próba pobrania złożonej struktury funkcją przeznaczoną do wartości prostych może zwrócić NULL albo nie dać oczekiwanego rezultatu.

Ścieżka JSON wskazuje położenie właściwości w dokumencie. Może prowadzić przez obiekt nadrzędny do zagnieżdżonego klucza, a także do elementu tablicy. W zapytaniach trzeba uwzględnić, że nazwa właściwości może nie istnieć, mieć wartość NULL albo występować w innym miejscu niż zakłada aplikacja. Obsługa takich przypadków powinna być świadoma, ponieważ nieodróżnienie braku klucza od pustej wartości może zmienić wynik filtrowania lub aktualizacji.

OPENJSON rozbija obiekt albo tablicę na wiersze i może zwracać klucze, wartości oraz ich typy. Z użyciem klauzuli WITH da się zdefiniować schemat odczytu i przekształcić wybrane właściwości na kolumny relacyjnego wyniku. Dzięki temu dane z dokumentu można łączyć z innymi tabelami, filtrować, agregować i przekazywać do dalszych etapów zapytania. Przy większej liczbie rekordów warto sprawdzić plan wykonania, ponieważ wielokrotne analizowanie dużych dokumentów tekstowych może obciążać procesor.

SQL Server potrafi również generować JSON na podstawie wyników relacyjnych. Klauzule FOR JSON PATH i FOR JSON AUTO tworzą dokumenty z wierszy zapytania, przy czym PATH daje większą kontrolę nad nazwami właściwości i zagnieżdżeniami. JSON_QUERY bywa używana przy budowaniu dokumentu, gdy fragment powinien pozostać obiektem lub tablicą, a nie zostać potraktowany jako zwykły tekst. Po stronie aplikacji należy sprawdzić, czy wynik ma być pojedynczym obiektem, tablicą, czy tekstem zawierającym dokument.

JSON_MODIFY umożliwia zmianę wskazanej właściwości bez ręcznego składania całego tekstu. Można zaktualizować istniejącą wartość, dodać nową albo usunąć właściwość zgodnie z użytym trybem operacji. Aktualizacja dokumentu jest jednak operacją na całej wartości NVARCHAR. Jeżeli kilka procesów modyfikuje ten sam rekord, trzeba uwzględnić współbieżność i ryzyko nadpisania zmiany zapisanej przez inny proces.

Gdzie pojawiają się błędy i niejasności

Jednym z częstych problemów jest przechowywanie w JSON wartości, które wyglądają jak liczby lub daty, lecz w rzeczywistości są tekstem. Porównanie tekstowe może dać inny rezultat niż porównanie liczbowe, a sortowanie dat zapisanych w niespójnym formacie może być nieprawidłowe. Jeżeli wartość ma znaczenie obliczeniowe, powinna być jawnie konwertowana do odpowiedniego typu podczas odczytu, a błędne konwersje powinny być obsługiwane zamiast ukrywane.

Niepoprawny dokument może trafić do bazy wtedy, gdy aplikacja wykonuje zapis bez wcześniejszej walidacji, gdy dane pochodzą z importu albo gdy aktualizacja składa tekst ręcznie. Warto kontrolować poprawność zarówno w kodzie aplikacji, jak i przy zapisie w SQL Server. Ograniczenie CHECK z ISJSON może zabezpieczyć kolumnę przed częścią błędów, lecz nie sprawdzi wszystkich reguł domenowych, takich jak obowiązkowe klucze, dozwolone wartości czy wzajemna zależność pól.

Problemy powodują także różne konwencje nazewnicze. Dokument raz może używać klucza „deviceId”, a innym razem „device_id”. Podobne rozbieżności dotyczą wielkości liter, zagnieżdżenia obiektów i sposobu zapisu wartości pustych. Przed wdrożeniem integracji należy ustalić jeden kontrakt danych oraz wersjonowanie zmian. Dodanie nowej właściwości zwykle jest łatwiejsze do obsługi niż zmiana znaczenia już istniejącej, ponieważ starszy kod może nadal oczekiwać poprzedniego formatu.

Wydajność pogarsza się, gdy kolumna zawiera duże dokumenty, a zapytania regularnie filtrują po tych samych właściwościach. Odczytywanie JSON w każdym wierszu może wymagać dodatkowej pracy podczas skanowania tabeli. W zależności od wersji SQL Server i charakteru zapytań można rozważyć kolumny obliczane wyprowadzające najczęściej używane wartości oraz indeksowanie tych kolumn. Rozwiązanie powinno być poprzedzone pomiarem, bo indeks zwiększa koszt zapisu i zajmuje miejsce.

Warto odróżnić problem danych od problemu aplikacji. Jeżeli ISJSON potwierdza poprawną składnię, a zapytanie nie zwraca oczekiwanej wartości, przyczyną może być błędna ścieżka, niewłaściwa funkcja, niezgodny typ albo różnica między pojedynczym obiektem a tablicą. Diagnostyka powinna obejmować rzeczywistą zawartość kolumny, zapytanie odczytujące, parametry przekazane przez aplikację i moment, w którym dokument został zapisany.

Praktyczna diagnostyka na komputerze użytkownika

Problemy związane z JSON często ujawniają się po awarii laptopa lub komputera, gdy aplikacja nie może odczytać lokalnej konfiguracji, pliku danych albo kopii roboczej bazy. Przed naprawą warto zabezpieczyć nośnik i wykonać kopię dostępnych danych, aby diagnostyka nie pogorszyła ich stanu. Sam fakt, że dane mają format JSON i są przechowywane jako NVARCHAR, nie oznacza jeszcze, że można je bezpiecznie odzyskać przez zwykłe kopiowanie plików.

Warszawskie Pogotowie Komputerowe zapewnia naprawę i diagnostykę sprzętu komputerowego — laptopów i komputerów stacjonarnych. Przy zgłoszeniu związanym z bazą zawierającą dokumenty JSON najważniejsze jest opisanie objawów, wskazanie nośnika, podanie informacji o wcześniejszych próbach uruchomienia oraz zaznaczenie, czy istnieje kopia zapasowa.

Do serwisu warto zgłosić komputer, gdy system nie uruchamia aplikacji korzystającej z lokalnych danych, dysk zgłasza błędy odczytu, urządzenie samoczynnie się wyłącza albo pliki z konfiguracją stały się niedostępne. W przypadku podejrzenia uszkodzenia nośnika należy ograniczyć dalsze zapisy, ponieważ nowe dane mogą nadpisać fragmenty potrzebne do odzysku. Rzadko spotykany dziś starszy sprzęt także może wymagać indywidualnej diagnostyki, zwłaszcza gdy dostęp do danych zależy od konkretnego interfejsu dysku lub nietypowych elementów komputera.

Jeśli nośnik jest sprawny, a problem dotyczy wyłącznie treści dokumentu, potrzebne będą dodatkowo informacje z aplikacji i SQL Server: komunikat błędu, przykładowy rekord, wynik kontroli poprawności oraz opis operacji, która poprzedziła awarię. Takie dane pomagają rozdzielić uszkodzenie sprzętu od błędu zapisu, niezgodności formatu lub problemu z zapytaniem. Bez tej granicy łatwo przypisać usterkę komputerowi, mimo że przyczyna znajduje się w logice aplikacji albo strukturze danych.