Szeroka Perspektywa Full-Stack Web Developmentu: Rodzaje relacji

0:00W tej lekcji pokażę Ci rodzaje relacji, a przynajmniej te najpopularniejsze, które

0:04występują w przypadku zarówno składowych, jak i składowych baz danych.

0:08Pierwszym rodzajem połączenia jest połączenie,

0:11które zachodzi pomiędzy tabelami, tak jak pokazywałem w jednej z poprzednich lekcji.

0:16Chodzi o to, że poszczególne wiersze tych

0:17tabel połączone są ze sobą identyfikatorem.

0:20Konkretnie użytkownicy posiadają swoje identyfikatory, a do tabeli Profile jest

0:25po prostu odniesienie do wiersza z tabeli users.

0:28Dzięki temu jesteśmy w stanie napisać zapytanie pobierające informacje o

0:32użytkowniku oraz o profilu, który posiada jego identyfikator.

0:36I teraz jeżeli chodzi o taką relację, to

0:38nieco inaczej wygląda to w przypadku MongoDB.

0:41Po pierwsze jeżeli chodzi o relacje

0:44to faktycznie też już powiedzieliśmy sobie, że możemy po prostu przechowywać

0:47tablicę identyfikatorów wskazującą na inną kolekcję.

0:52Z drugiej jednak strony możemy mieć też relację, czyli relację jeden do kilku.

0:57W tym przypadku mowa np.

0:59o sytuacji, w której mamy rolę użytkownika

1:02i nie ma potrzeby tworzenia oddzielnej kolekcji, aby je przechowywać.

1:05Tylko w zamian przechowujemy je

1:07bezpośrednio w tablicy pola przechowywanego wewnątrz danego dokumentu.

1:12Dzięki temu nie ma tutaj tej złożoności, która występuje w przypadku tabel oraz też

1:16pobieranie tych informacji jest zdecydowanie prostsze.

1:19Pamiętaj tylko proszę o tym, że w momencie gdy łączyć ze sobą informacje w taki

1:23sposób, musisz pamiętać o pewnych ograniczeniach.

1:26Mianowicie teoretycznie możesz mieć tutaj

1:28stosunkowo dużo informacji zapisanych wewnątrz takiej tablice.

1:32Jednocześnie jeżeli będzie ich zbyt dużo,

1:35doprowadzi to do dużej wagi samego dokumentu i za każdym razem, gdy będziesz

1:39go pobierać, będziesz pobierać też cały zestaw danych.

1:43W związku z tym w momencie, gdy faktycznie

1:44masz tylko kilka powiązań, nie ma problemu, aby wykorzystać tutaj embedded.

1:49Natomiast w przypadku, gdy tych elementów będzie więcej bądź będą bardziej

1:53rozbudowane, warto zobaczyć tutaj referencję do innej kolekcji.

1:57Kolejnym rodzajem relacji jest relacja Onetu maszyny, czyli jeden do wielu.

2:02W przypadku. Tutaj struktura tabeli wygląda dokładnie

2:04tak samo jak w poprzednim przykładzie, aczkolwiek różnica polega na tym, że np.

2:09tutaj nic nie stoi na przeszkodzie, aby jeden użytkownik miał przypisanych np.

2:13wiele różnych artykułów.

2:15Coś takiego jak najbardziej odzwierciedla sytuację, do której może dojść i

2:19jednocześnie też takie powiązanie jest uzasadnione.

2:22W momencie, gdy rozwijamy funkcje naszej aplikacji, takie jak np.

2:25wyświetlanie artykułów powiązanych z danym użytkownikiem.

2:29Warto tutaj jeszcze pamiętać o tym, o czym

2:32jeszcze do tej pory nie zdarzyło mi się wspomnieć.

2:34Mianowicie w przypadku tych

2:36identyfikatorów mówimy o tak zwanym kluczu obcym.

2:39Oznacza to, że tabela articles posiada swój klucz główny, ale też posiada klucze

2:44obce, które są powiązane z konkretną tabelą.

2:47Zatem teoretycznie moglibyśmy tutaj

2:49doprowadzić do sytuacji, w której artykuły są powiązane z jeszcze jedną tabelą i

2:53również wewnątrz tej kolumny będą zapisane identyfikatory np.

2:571.

2:58Nie będzie to jednak odgrywało większej roli, ponieważ kolumny zawierające klucze

3:02obce są powiązane ze ściśle określonymi tabelami.

3:06I teraz, jeżeli spojrzymy sobie, jak taka relacja wygląda w przypadku MongoDB,

3:11to tak naprawdę nie ma tutaj zaskoczenia, ponieważ po prostu mamy tablicę

3:15zawierającą listę identyfikatorów pochodzących z innej kolekcji.

3:19Jednocześnie też nie ma tego ścisłego powiązania pomiędzy tą konkretną kolekcją,

3:24ale to Twoja aplikacja definiuje skąd pobierane są te konkretne informacje.

3:29Ostatnim rodzajem relacji jest relacja,

3:32w przypadku której mówimy o powiązaniu wiele do wielu.

3:35Przykładem może być chociażby wspomniane

3:37wcześniej rola użytkownika, w przypadku których jeden użytkownik może posiadać

3:42wiele różnych ról ze względu na proces normalizacji.

3:45Musimy tutaj wykorzystać dodatkową tabelę pomocniczą, która będzie wiązać nam

3:50rekordy z tabeli Users z rekordami z tabeli.

3:54W rezultacie tworzymy tabelę Users,

3:56wewnątrz której posiadamy klucz główny oraz dwa klucze obce, z czego jeden

4:00wskazuje na rekordy z tabeli users, a drugi na rekordy z tabeli.

4:05W przypadku MongoDB sytuacja jest to

4:07zdecydowanie prostsza ze względu na to, że potrzebujemy tylko dwie kolekcje, wewnątrz

4:12których na przykład jeżeli mamy użytkownika, do którego są przypisane

4:15zadania, po prostu przechowujemy identyfikatory tych zadań.

4:18Z drugiej jednak strony w przypadku samych

4:20zadań posiadamy również właścicieli bądź też osoby przypisane do tych zadań.

4:25I tutaj ponownie wystarczają identyfikatory tych konkretnych wpisów.

4:29Trzeba jednak pamiętać o pewnego rodzaju

4:32możliwościach i jednocześnie ograniczeniach MongoDB.

4:35Mianowicie, tak jak powiedziałem, nie możemy doprowadzić do sytuacji polegającej

4:38na tym, że wewnątrz jednej tablicy będziemy mieć np.

4:41miliony rekordów.

4:43Takim sztandarowym przykładem jest

4:45sytuacja, w której przechowujemy logi serwera wewnątrz naszej bazy.

4:49I tutaj przykładowo mamy hosty, czyli np.

4:52nasz główny serwer, w ramach którego możemy mieć potrzebę zapisywania logów,

4:56zamiast przechowywać tutaj identyfikatory logów.

5:00Z tym hostem, to realizujemy tutaj odwrotną relację, polegającą na tym, że w

5:04kolekcji logs wskazujemy na hosta, z którym są powiązane.

5:08Dzięki temu, niezależnie od tego, ile tych

5:10dokumentów będzie, nigdy nie doprowadzimy do sytuacji, w której np.

5:14przekroczymy limit na jeden dokument, który wynosi 16 MB.

5:19Zatem jeżeli spojrzymy na sposoby projektowania i łączenia

5:24informacji zarówno w tabelach, jak i kolekcjach, to zobaczymy pomiędzy nimi

5:28trochę analogii, ale jednocześnie samo podejście zasadniczo się różni.

5:33Jeżeli zdecydujesz się na bazę MongoDB, pamiętaj, że Twoim nadrzędnym celem nie

5:38jest to, aby odwzorowywać techniki, które może znać np.

5:42z relacyjnych baz danych, ale to, aby dostosować strukturę dokumentów do Twojej

5:47aplikacji i do tego, w jaki sposób potrzebujesz pracować z tymi danymi.

5:52Jeżeli chodzi o praktyczne wykorzystanie

5:54tej wiedzy, to wydaje mi się, że nie pozostaje nic innego jak np.

5:58wykorzystanie najlepiej do tego, aby postawić sobie nowy projekt, wewnątrz

6:02którego skonfigurujemy sobie bazę w SQL, bądź też np.

6:06MongoDB i po prostu pobawimy się w

6:08projektowanie przykładowo w charakterystycznej dla zwykłego bloga,

6:13bądź na przykład serwisu z ogłoszeniami o pracę.

6:16Możesz to potraktować jako zadanie domowe, aczkolwiek muszę zaznaczyć, że warto je

6:20odłożyć na czas po tym, jak przejdziemy sobie przez proces projektowania bazy

6:25danych wspólnie w ramach projektu realizowanego.

6:28Czy jest na ten moment jednak to byłoby na

6:31tyle, więc dziękuję Ci za uwagę i zapraszam do kolejnych materiałów.