Czy ktoś używa HierarchyId w rzeczywistej produkcji z tabelami o rozsądnych rozmiarach, przekraczającymi kilka tysięcy wierszy? Czy jest niezawodny / wydajny? Do tej pory nie znalazłem nikogo, kto nie jest powiązany ze sprzedawcą, polecam go, a Paul Nielsen odradza to tutaj .
Jakie jest Twoje doświadczenie w korzystaniu z HierarchyId w rzeczywistych systemach produkcyjnych?
Jakie kryteria zastosowałeś, wybierając HierarchyId zamiast jego alternatyw?
Odpowiedzi:
Wdrożyłem HierarchyID i stwierdziłem, że zapewnia dobrą wydajność i jest łatwy w użyciu.
Użyłem go w relatywnie małych zestawach danych (dziesiątki tysięcy wierszy) z hierarchią do 10 gałęzi.
Po co z tego korzystać? Typ HierarchyID zapewnia szereg metod pomocniczych (takich jak IsDescendantOf), które ułatwiają pracę niż tworzenie własnej zmaterializowanej ścieżki.
Komentarz Paula Nielsena do StackOverflow jest dla mnie mylący - HierarchyID to zmaterializowana ścieżka. Bardziej skłonny jestem zgodzić się z tym komentarzem pod jego odpowiedzią.
Lepszym pytaniem może być „dlaczego tego nie wykorzystać”. Jest łatwy w użyciu, zapewnia wiele funkcji, które w innym przypadku napisałbyś dla siebie, i działa dobrze (w moich ograniczonych testach).
To jest odpowiedź na pytanie Kirka „dlaczego go nie używać (HierarchyId)”. W porównaniu do zmaterializowanej ścieżki, w niektórych ważnych przypadkach Hierarchia wydaje się być zarówno mniej wydajna, jak i mniej wygodna w pracy.
Powód jest prosty: cytując komentarz Microsoftu na temat Connect : „Problem polega na tym, że wywołania CLR, w tym metody hierarchyID, są nieprzejrzyste dla optymalizatora zapytań. Jest to zgodne z projektem. Jednak oznacza to, że oszacowanie liczności dla nich może czasami być dość źle."
Z drugiej strony, implementacja zmaterializowanej ścieżki jest bardzo łatwa za pierwszym razem, gdy musimy to zrobić, a następnym razem będzie to w zasadzie zadanie kopiowania i wklejania. Tak więc otrzymujemy bardziej wszechstronne i lepiej działające rozwiązanie przy bardzo małym wysiłku.
Całkowicie zgadzam się z Paulem Nielsenem, który napisał w swojej doskonałej książce zatytułowanej „Biblia Microsoft® SQL Server® 2008”: „Nowy HierarchyID nie jest bezsporny. Jest nowy i dostaje dużo czasu na prasę i demo, ale ja” Nie jestem pewien, czy to problem, który wymagał innego rozwiązania. ”
Moja firma korzysta z HeirachyID w sprzedaży bezpośredniej, wielopoziomowego oprogramowania marketingowego. To działa. Tak naprawdę nie zrobiłem z tym żadnej pracy, po prostu wiem, że go używamy.
Największym problemem, jaki z tym widziałem, jest to, że iterujemy poziomy w sposób zapętlony, a nie bardziej oparty na zestawie. W tym obszarze nie działa nam dobrze, ale nie jestem pewien, czy jest to problem z typem lub naszą implementacją.
Jednym z problemów z hierarchyid jest zablokowanie dostawcy. Ale znalazłem świetny artykuł Adama Milazzo o tym, jak wszystko działa wewnętrznie:
http://www.adammil.net/blog/view.php?id=100
Dzięki temu mogłem napisać skrypt Postgres do konwersji mojego zestawu danych z MSSQL. Zawarłem go również w skrypcie, który napisałem, aby zaimportować bazę danych AdventureWorks do Postgres:
https://github.com/lorint/AdventureWorks-for-Postgres
Wystarczy wyszukać „hierarchyid” w pliku install.sql, a wkrótce znajdziesz odniesienia do jego konwersji.
Nasz zespół wdrożył go w produkcji, początkowo wydajność jest dobra, po 2 latach tabela zawiera teraz 430 000 wierszy, a getroot i getdecendent zajmuje 3 sekundy, oba są wymagane do obliczenia następnej wartości Id do wstawienia rekordu. Teraz wstawienie pojedynczego poddrzewa zajmuje około 16 sekund, co jest w ogóle nie do przyjęcia.