Jaki byłby najlepszy sposób wdrożenia struktury danych drzewiastych w bazie danych, która można dostosować (czyli struktura drzewa o nieznanej liczbie poziomów)?Struktura bazy danych dla struktury danych drzewa
Zrobiłem to raz przed użyciem tabeli z obcym kluczem do siebie.
Jakie inne implementacje można zobaczyć i czy ta implementacja ma sens?
można wymienić najczęściej wdrożone, który jest adjacency Lista: https://blogs.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets
Istnieją inne modele, jak również, w tym zmaterializowanej ścieżkę i zagnieżdżonych zestawów: http://communities.bmc.com/communities/docs/DOC-9902
Joe Celko napisał książkę na ten temat Temat, który jest dobrym odnośnikiem z ogólnej perspektywy SQL (jest wspomniany w powyższym linku zagnieżdżonego zestawu artykułów).
Ponadto Itzik Ben-Gann ma dobry przegląd najczęstszych opcji w swojej książce "Inside Microsoft SQL Server 2005: T-SQL Querying".
Główne rzeczy do rozważenia przy wyborze modelu to:
1) Częstotliwość zmiany struktury - jak często ma rzeczywistą strukturę zmianą drzewa. Niektóre modele zapewniają lepszą charakterystykę aktualizacji struktury. Ważne jest jednak oddzielenie zmian struktury od innych zmian danych. Na przykład możesz modelować wykres organizacyjny firmy. Niektórzy ludzie będą modelować to jako listę przyległości, używając identyfikatora pracownika, aby powiązać pracownika z przełożonym. Zwykle jest to podejście nieoptymalne. Podejście, które często działa lepiej, polega na modelowaniu struktury organizacyjnej odrębnej od samych pracowników i utrzymaniu pracownika jako atrybutu struktury. W ten sposób, gdy pracownik opuszcza firmę, sama struktura organizacyjna nie musi być zmianą, tylko związek z pozostawionym pracownikiem.
2) Czy drzewo jest ciężkie lub ciężkie do przeczytania - niektóre struktury działają bardzo dobrze podczas czytania struktury, ale ponoszą dodatkowe obciążenie podczas pisania do struktury.
3) Jakie rodzaje informacji należy uzyskać ze struktury - niektóre struktury wyróżniają się dostarczaniem określonych informacji o strukturze. Przykłady obejmują znalezienie węzła i wszystkich jego elementów podrzędnych, znalezienie węzła i wszystkich jego rodziców, znalezienie liczby węzłów podrzędnych spełniających określone warunki itd.Musisz wiedzieć, jakie informacje będą potrzebne ze struktury, aby określić strukturę, która najlepiej pasuje do Twoich potrzeb.
Cześć, mam do czynienia z tym samym problemem określonym w pytaniu i chciałbym zadać ci pytanie na powyższe tematy. Biorąc pod uwagę strukturę, jak w przypadku tematu numer jeden (tabela struktury organizacyjnej (nie ma struktury pracownika) z nadrzędnym odnośnikiem w tej samej tabeli), muszę określić, kto jest szefem określonego obszaru. Przydzielę wszystkim pracownikom tego konkretnego obszaru bezpośrednio do niego. Gdzie postawisz szefa tego konkretnego obszaru? Wewnątrz tego samego obszaru lub jednego gorupa powyżej? Moje podejście polega na odwołaniu się do grupy powyżej, co wydaje mi się lepszą strukturą. Dzięki. –
Pierwszy link wydaje się być uszkodzony. –
@J. C. Leitão - Dzięki, zaktualizowałem link. – JeremyDWill
Spójrz na Managing Hierarchical Data in MySQL. Omówiono dwa podejścia do przechowywania i zarządzania hierarchicznymi (drzewiastymi) danymi w relacyjnej bazie danych.
Pierwsze podejście to model listy sąsiedztwa, który zasadniczo opisuje się: posiadanie klucza obcego, który odnosi się do samej tabeli. Chociaż takie podejście jest proste, może być bardzo nieefektywne w przypadku niektórych zapytań, takich jak budowanie całego drzewa.
Drugie podejście omówione w artykule to zagnieżdżony model zestawu. Takie podejście jest znacznie bardziej wydajne i elastyczne. Zapoznaj się z artykułem, aby uzyskać szczegółowe wyjaśnienia i przykładowe zapytania.
twój link ma bardzo ciekawy temat jest omawiane. dzięki! – Fritz
Posiadanie stołu z obcym kluczem dla siebie ma dla mnie sens.
Następnie można użyć wspólnego wyrażenia tabelowego w SQL lub połączyć za pomocą wcześniejszego polecenia w Oracle, aby zbudować drzewo.
Mam tabela dziennika, z kolumna tożsamości LogID i kolumna ParentLogID z FK, który wskazuje z powrotem do kolumny LogID. Kiedy jest zapisywany pierwszy wiersz dziennika w transakcji, pobieram SCOPE_IDENTITY(). Wszystkie inne zapisy dziennika są zapisywane z tą wartością w kolumnie ParentLogID. Jest to bardzo przydatne do grupowania wierszy, które należą do siebie. To jedyny prawdziwy sposób, by zobaczyć, co się stało, bez tego byłby to ogromny bałagan w wierszach z wielu transakcji, które byłyby razem pomieszane. –
@KM - Powiedział "ma sens", nie "nie ma sensu" –
Użyłem następujący wdrożenia na SQL Server 2005. Sprawdź here
wspaniałą kolekcją gotowe do użycia funkcje, które mogą być używane z listy Model przylegania, aby uczynić życie prostszym.
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html
Jeśli trzeba użyć relacyjnej bazy danych do organizowania struktury danych PostgreSQL drzewo następnie chłodną moduł ltree który zapewnia reprezentujący typ danych dla etykiet danych przechowywanych w postaci hierarchicznej struktury drzewiastej. Możesz uzyskać pomysł stamtąd. (Aby uzyskać więcej informacji, zobacz: http://www.postgresql.org/docs/9.0/static/ltree.html)
W powszechnym LDAP służy do porządkowania rekordów w strukturze hierarchicznej.
Zobacz: [Jakie są opcje przechowywania danych hierarchicznych w relacyjnej bazie danych?] (Http://stackoverflow.com/questions/4048151/what-are-the-options- for-storing-hierarchical-data-in -a-relacyjna-baza danych) – cbare
Serwer SQL (od 2008 r.) oferuje [typ danych hierarchii] (https://msdn.microsoft.com/en-us/library/bb677290.aspx) – BornToCode