HierarchyID

HierarchyID to typ danych SQL Server umożliwiający efektywne przechowywanie i przetwarzanie struktur hierarchicznych.

Typ hierarchyid i zapis położenia w drzewie

hierarchyid to systemowy typ danych dostępny w Microsoft SQL Server, przeznaczony do reprezentowania pozycji w hierarchii, czyli relacji nadrzędny–podrzędny. Wartość tego typu opisuje drogę od korzenia do konkretnego węzła. Przykładowo zapis / oznacza korzeń, /1/ może oznaczać jego bezpośrednie dziecko, a /1/2/ potomka tego węzła. Poszczególne elementy ścieżki są rozdzielane ukośnikami, a cała wartość jest ujmowana między nimi. Taki zapis nie przechowuje nazwy działu, kategorii ani innego obiektu biznesowego; reprezentuje wyłącznie jego położenie w strukturze.

hierarchyid jest typem CLR systemu SQL Server, ale korzysta się z niego w tabeli jak z kolumny danych. Nie narzuca automatycznie unikalności ani relacji klucza obcego pomiędzy węzłami. To oznacza, że projekt tabeli musi osobno określać, czy wartości mają być unikalne, czy każdy węzeł musi mieć istniejącego rodzica oraz jak mają być przechowywane atrybuty opisujące obiekt. Sama kolumna hierarchyid nie zastępuje identyfikatora biznesowego, nazwy, opisu ani innych danych rekordu.

Metody wyznaczania rodziców, dzieci i potomków

SQL Server udostępnia dla hierarchyid metody pozwalające odczytywać i budować relacje w drzewie. GetLevel() zwraca poziom węzła, liczony względem korzenia. GetAncestor(n) zwraca przodka oddalonego o określoną liczbę poziomów, dlatego dla wartości /1/2/ wywołanie z argumentem jeden prowadzi do /1/. Metoda GetDescendant(child1, child2) służy do wyznaczenia wartości dla nowego dziecka pomiędzy wskazanymi sąsiednimi węzłami albo przed pierwszym lub za ostatnim dzieckiem. Jej wynik jest wartością hierarchyid, a nie automatycznie wygenerowaną nazwą lub numerem rekordu.

Porównywanie wartości hierarchyid ma znaczenie przy sortowaniu i wyszukiwaniu poddrzew. Metoda IsDescendantOf() pozwala sprawdzić, czy jeden węzeł znajduje się pod drugim w hierarchii. W zapytaniach można również używać operatorów porównania, aby ograniczyć wynik do zakresu odpowiadającego poddrzewu, pod warunkiem że zapytanie i indeks zostały zaprojektowane z uwzględnieniem porządku wartości. Metoda ToString() zwraca tekstową postać ścieżki, natomiast Parse() pozwala utworzyć hierarchyid na podstawie poprawnego zapisu tekstowego.

Przy dodawaniu rekordu aplikacja lub procedura składowana musi ustalić jego pozycję w drzewie. Zwykle pobiera się wartość rodzica, a następnie wywołuje GetDescendant(), przekazując poprzednie i następne dziecko w kolejności określonej przez aplikację. Po przeniesieniu gałęzi trzeba zmienić wartości hierarchyid w przenoszonym węźle oraz jego potomkach, ponieważ ścieżka każdego potomka zawiera identyfikatory wszystkich przodków. Aktualizacja samego rekordu rodzica nie przenosi automatycznie całego poddrzewa.

Indeksy, sortowanie i konsekwencje zmiany struktury

Kolumnę hierarchyid można indeksować, a sposób indeksowania powinien odpowiadać dominującym zapytaniom. Indeks klastrowany według hierarchyid może grupować rekordy w kolejności zbliżonej do porządku drzewa, dzięki czemu odczyt węzła wraz z jego potomkami może być efektywny. Indeks nie zapewnia jednak sam z siebie poprawności hierarchii. Jeżeli wymagane jest, aby dwa rekordy nie miały tej samej pozycji, potrzebne jest ograniczenie unikalności albo inny mechanizm kontroli po stronie bazy.

Wartość hierarchyid jest zmienna pod względem długości zapisu. Jej rozmiar zależy od liczby poziomów oraz sposobu numerowania elementów ścieżki, dlatego bardzo głębokie drzewa i częste wstawianie elementów pomiędzy istniejące węzły wymagają testów na rzeczywistych danych. Metoda GetDescendant() może generować wartości pośrednie, lecz przy wielokrotnym zagęszczaniu tego samego miejsca ścieżki mogą stawać się dłuższe. W praktyce może to zwiększać rozmiar indeksów i koszt późniejszych operacji.

hierarchyid jest odpowiedni dla danych naturalnie hierarchicznych, takich jak struktura organizacyjna, katalog kategorii albo drzewo elementów. Nie jest natomiast uniwersalnym mechanizmem dla każdego rodzaju grafu. Wartość opisuje jedną ścieżkę w drzewie, a nie dowolną liczbę relacji między węzłami. Jeżeli obiekt może mieć wielu rodziców, relacje cykliczne albo niezależne krawędzie, model oparty wyłącznie na hierarchyid nie odwzoruje tych zależności. Przy projektowaniu tabeli trzeba także zdefiniować zachowanie podczas usuwania rodzica, przenoszenia gałęzi i równoczesnego dodawania dzieci.

Kontrola danych hierarchyid w środowisku SQL Server

Diagnostyka problemów z hierarchyid obejmuje sprawdzenie typu kolumny, wartości ścieżek, indeksów oraz zapytań wykonujących operacje na drzewie. Należy zweryfikować, czy wartości są poprawnie parsowane, czy nie występują niezamierzone duplikaty oraz czy rekordy posiadają oczekiwanych przodków. Przy analizie wolnego zapytania trzeba sprawdzić plan wykonania i selektywność indeksu, ponieważ samo zastosowanie typu hierarchyid nie gwarantuje użycia indeksu ani krótkiego czasu odpowiedzi.

Podczas przenoszenia węzła kontrola powinna objąć całą gałąź. Zmiana ścieżki rodzica bez przeliczenia wartości potomków pozostawia niespójny model logiczny: rekordy nadal będą miały stare ścieżki, więc zapytania wykorzystujące IsDescendantOf(), GetAncestor() lub sortowanie po hierarchyid mogą zwracać nieoczekiwane wyniki. Operację taką należy wykonywać jako spójny zestaw zmian, z warunkami ograniczającymi zakres aktualizowanych rekordów i z weryfikacją rezultatu po zakończeniu.

W przypadku problemów z aplikacją korzystającą z SQL Server warto rozdzielić błąd danych od błędu kodu. Niepoprawna wartość w kolumnie może wynikać z błędnego wyznaczenia rodzica, pominięcia kontroli unikalności, nieprawidłowego sortowania dzieci albo niepełnej migracji poddrzewa. Analiza powinna obejmować definicję tabeli, procedury i zapytania odczytujące hierarchyid, a także rzeczywiste wartości zapisane w bazie. Takie podejście pozwala ustalić, czy problem dotyczy struktury hierarchii, indeksowania, czy jedynie prezentacji ścieżki w aplikacji.