Jak zawsze:nie ma najlepszego rozwiązania. Każde rozwiązanie sprawia, że różne rzeczy są łatwiejsze lub trudniejsze. Właściwe rozwiązanie dla Ciebie zależy od tego, jaką operację wykonasz najczęściej.
Podejście naiwne z identyfikatorem rodzica:
Plusy:
-
Łatwy do wdrożenia
-
Łatwe przeniesienie dużego poddrzewa do innego rodzica
-
Wkładka jest tania
-
Potrzebne pola bezpośrednio dostępne w SQL
Minusy:
-
Pobieranie całego drzewa jest rekurencyjne, a zatem drogie
-
Znalezienie wszystkich rodziców też jest drogie (SQL nie zna rekurencji...)
Zmodyfikowane przechodzenie przez drzewo zamówień w przedsprzedaży (zapisywanie punktu początkowego i końcowego):
Plusy:
-
Pobranie całego drzewa jest łatwe i tanie
-
Znalezienie wszystkich rodziców jest tanie
-
Potrzebne pola bezpośrednio dostępne w SQL
-
Bonus:zapisujesz również kolejność węzłów podrzędnych w jego węźle nadrzędnym
Minusy:
- Wstawianie/aktualizacja może być bardzo kosztowne, ponieważ być może będziesz musiał zaktualizować wiele węzłów
Zapisywanie ścieżki w każdym węźle:
Plusy:
-
Znalezienie wszystkich rodziców jest tanie
-
Pobranie całego drzewa jest tanie
-
Wstawianie jest tanie
Minusy:
-
Przenoszenie całego drzewa jest drogie
-
W zależności od sposobu, w jaki zapiszesz ścieżkę, nie będziesz w stanie pracować z nią bezpośrednio w SQL, więc zawsze będziesz musiał ją pobrać i przeanalizować, jeśli chcesz ją zmienić.
Tabela zamknięcia
Plusy:
-
Łatwy do wdrożenia
-
Znalezienie wszystkich rodziców jest tanie
-
Wstawianie jest tanie
-
Pozyskiwanie całych drzew jest tanie
Minusy:
-
Potrzebuje dodatkowego stołu
-
Zajmuje dużo miejsca w porównaniu z innymi podejściami
-
Przenoszenie poddrzewa jest drogie
Wolałbym jeden z dwóch ostatnich, w zależności od tego, jak często zmieniają się dane.
Zobacz też:http://media.pragprog.com/titles/bksqla/trees. pdf
