Próbuję zaimplementować strukturę drzewa podobnego do opisanego tutaj: http://www.dbazine.com/oracle/or-articles/tropashko4.Wymuszenie spójności referencyjnej na zmaterializowanej ścieżce?
Czy można wyegzekwować integralność referencyjną w polu [ścieżka]? Nie widzę, jak SQL może to zrobić, czy muszę to zrobić ręcznie w DAL?
Tak, musisz samodzielnie wymusić integralność danych w oprogramowaniu DAL, gdy używasz rozwiązań Ścieżka zmaterializowana lub Zestawów zagnieżdżonych dla danych hierarchicznych.
Lista sąsiedztwa obsługuje integralność referencyjną, a dotyczy to również projektu, który nazywam "Closure Table" (Tropashko nazywa ten projekt "relacją zamknięcia przechodniego").
W zmaterializowanym modelu ścieżki można używać dowolnych łańcuchów (może łańcuchów unicode, aby zezwalać na więcej niż 256 dzieci) zamiast specjalnych łańcuchów formularza "x.y.z". Identyfikator jednostki nadrzędnej jest wówczas identyfikatorem bezpośrednich potomków z usuniętym ostatnim znakiem. Można łatwo egzekwować to z ograniczeniem wyboru jak (mój przykład działa w PostgreSQL)
check(parent_id = substring(id from 1 for char_length(id)-1)),
w swoim poleceniu tworzenia tabeli. Jeśli nalegasz na ciągi w formie "x.y.z", będziesz musiał bawić się za pomocą wyrażeń regularnych, ale domyślam się, że można znaleźć odpowiednie ograniczenie sprawdzające.
Jeśli chcesz wymusić, że root ma char_length (id) = 1, możesz dodatkowo dodać sprawdzanie ograniczeń ((parent_id ma wartość null) lub (char_length (id) = 1)) do definicji tabeli. – Whoever
"Zmaterializowana ścieżka" przedstawiona przez Vadima Tropashko w tym artykule wprowadza pojęcie porządku do relacji ("Jones jest drugim członkiem").
"Zmaterializowana ścieżka" jest niczym innym, jak "jakąś formą zmaterializowanego widzenia" na przechodnie zamknięcie, i dlatego cierpi na wszystkie i dokładnie takie same problemy, jak każdy inny "zmaterializowany widok", z tym że sprawy są algorytmicznie gorsze właśnie z powodu zaangażowanie zamknięcia.
SQL jest prawie całkowicie bezsilny, gdy w grę wchodzą ograniczenia w trakcie zamykania. (To znaczy: tak, SQL wymaga, abyś zrobił wszystko samemu.) To jedna z tych dziedzin, w których RM pokazuje maksimum swojej prawie nieograniczonej mocy, ale SQL nie działa niepoprawnie, a gdzie to wstyd, że większość ludzi błędnie SQL za relacje.
(@Bill Karwin: Chciałbym móc dać +1 za twoją uwagę na temat związku między głębokością drzew a wynikiem na wydajności. Nie ma znanych algorytmów do obliczania zamknięć, które dobrze się sprawdzają w przypadku drzew "crazy" głębokościach. jest to algorytmiczne problemem, a nie SQL ani relacyjnym jeden).
EDIT
Tak, RM = model relacyjny
RM = model relacyjny? – hyperslug
+1 Tak, zmaterializowana ścieżka jest przykładem denormalizacji. Ma pewne zalety wydajności w przypadku niektórych typów zapytań, ale rezygnuje z zalet RM, takich jak integralność referencyjna. –
Przy okazji, możesz najechać kursorem myszy na niewidoczną strzałkę w górę na lewo od komentarza i nieco poprzeć komentarz. To jednak nie daje punktów rep. –
Tak, możemy „egzekwować integralność referencyjna w polu [ścieżka] ". Zrobiłem to kilka lat temu, opisane tutaj:
Store your configuration settings as a hierarchy in a database
Dzięki za info, Bill. – hyperslug
Oto artykuł na temat rozwiązania zamknięcia przechodniego: http://www.codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx @Bill Karwin: jak duże zestawy danych zostały wdrożone przy użyciu "tabel zamknięcia" w scenariuszach OLTP/interaktywnych bez uderzania wydajności problemy z insertami? – nawroth
@nawroth: Tylko na rzędu tysięcy węzłów w drzewie, więc dobry punkt. Jeśli potrzebujesz reprezentować bardzo głębokie drzewa, kończysz z wieloma wierszami. Jeśli potrzebujesz reprezentować wiele płytkich drzew, jest to skromniejsze. –