Szeroka Perspektywa Full-Stack Web Developmentu: Zasady projektowania baz danych

0:00W tym momencie proponuję, abyśmy przyjrzeli się trochę temu, w jaki sposób

0:04w ogóle wyglądają bazy danych i jak się je projektuje oraz co dużej bazy SQL od SQL.

0:10Mianowicie niemal każda aplikacja

0:12przechowuje informacje na temat użytkowników.

0:15W przypadku bazy SQL będzie to tabela, wewnątrz której musimy zdefiniować

0:19kolumnę, a następnie dodać do niej poszczególne wiersze, które dokładnie

0:23zawierają informacje na temat użytkowników.

0:26Naturalnie tych kolumn może być

0:28zdecydowanie więcej, ale w związku z tym, że mamy do czynienia z tabelą, to od razu

0:32musimy określić jakie kolumny występują w przypadku użytkowników.

0:36Przykładowo, jeżeli zdecydujemy się na

0:38dodanie nowej kolumny do tabeli users, to będzie ona obecna w przypadku każdego

0:43użytkownika, niezależnie czy to pole jest uzupełnione czy też nie.

0:47Naturalnie też możemy określić tutaj typ danej kolumny, czyli np.

0:50możemy doprecyzować czy chcemy przechowywać ciągi znaków czy np.

0:54liczby lub też nawet obiekty Jameson.

0:56Aczkolwiek w tym przypadku trzeba przyznać, że bazy danych SQL raczej nie

1:01zostały zaprojektowane z myślą o obiektach Agile.

1:04W każdym razie to co musisz wiedzieć na temat baz danych SQL to fakt, że są one

1:08niczym innym jak specjalnymi tabelami, w ramach których masz zdefiniowane kolumny,

1:12wiersze oraz dodatkowo różne ustawienia dotyczące poszczególnych kolumn.

1:17Najważniejsze jest jednak to, że w związku

1:19z tym, że mamy do czynienia z tabelą, siłą rzeczy zachowujemy tutaj z góry określoną

1:23strukturę, w przypadku której nie ma znaczenia to, czy dany wiersz posiada

1:27jakieś pole, czy też nie, ponieważ kolumna w jego przypadku jest obecna.

1:31Jednym z ważniejszych elementów

1:33projektowania baz danych jest to, w jaki sposób poukładane informacje, które mogą

1:37znajdować się wewnątrz wielu różnych tabel.

1:40Przykładowo, jeżeli wyobrazimy sobie, że użytkownicy mogą pisać artykuły,

1:45to najlepszym sposobem ich przechowywania jest utworzenie nowej tabeli, wewnątrz

1:49której będziemy przechowywać informacje na temat artykułów.

1:53Ale jednocześnie jak widzisz, mamy tutaj kolumnę User ID, która wskazuje na

1:57identyfikator konkretnego rekordu z tabeli Users.

2:00Oznacza to, że w tym przypadku oba

2:02artykuły zostały przypisane do Michała, więc w momencie, gdy np.

2:05będziemy chcieli pobrać informacje o nim, możemy wykonać tzw.

2:09join po to, aby pobrać również informacje na temat napisanych przez niego artykułów.

2:14Jednocześnie, jak widzisz, ogromną rolę

2:16odgrywają w tym całym procesie identyfikatory poszczególne ich wiersze.

2:20Z tego powodu co prawda zdarzyło mi się spotykać tabele, które nie posiadały

2:24kolumny ID, natomiast moim zdaniem unikanie tej kolumny jest złą praktyką i

2:28też negatywnie wpływa na wydajność odczytu takich informacji.

2:32W związku z tym taką ogólną zasadą, którą zawsze stosuję jest dodawanie tej kolumny

2:37do każdej tabeli, niezależnie od tego jakie dane wewnątrz niej przechowuje.

2:41Dzięki temu mam stosunkowo łatwo możliwość

2:44powiązania ze sobą rekordów i utworzenia relacji pomiędzy tabelami.

2:48No i teraz jak się pewnie domyślasz, takich relacji jest przynajmniej kilka

2:52rodzajów i każdy z nich spełni swoje zadanie w nieco innym przypadku.

2:56Jeżeli zastanawiasz się, dlaczego w ogóle musimy dzielić informacja

2:59na różne tabele, to odpowiedzią na to pytanie jest tzw.

3:03normalizacja.

3:04Jest to proces organizowania informacji w

3:06taki sposób, aby możliwie można było unikać duplikatów.

3:10No bo przykładowo w przypadku artykułów

3:12teoretycznie każdy artykuł należy do jednego użytkownika, ale jednocześnie

3:16dodawanie takiego faktu w przypadku tabel jest stosunkowo trudne.

3:20No bo tak naprawdę jedynym sposobem na to,

3:22aby przechowywać wiele artykułów powiązanych z jednym użytkownikiem byłoby

3:26to, aby przypisać do artykułu adres e-mail użytkownika, którego napisał.

3:31Natomiast jeżeli wyobrazisz sobie nawet prostego bloga, to obok artykułu raczej

3:35nie wyświetlamy adresu e-mail użytkownika, tylko na przykład jego imię i nazwisko.

3:40W związku z tym również te informacje

3:42musiałyby się znaleźć wewnątrz tabeli articles.

3:45Na teraz wyobraź sobie podstronę, na

3:47której chcielibyśmy wyświetlić artykuły, które napisał Michał.

3:51Musielibyśmy przede wszystkim znać jego adres email do tego, aby móc pobrać tylko

3:56te artykuły, w przypadku których został on przypisany.

3:59Natomiast co się stanie w momencie, gdy

4:01Michał zdecyduje się na zmianę swojego adresu email?

4:04Czy to doprowadzi do sytuacji, w której wszystkie wcześniej napisane przez niego

4:08artykuły przestaną być z nim powiązane, czy też np.

4:11będziemy musieli napisać kod, który

4:12zaktualizuje jego adres email we wszystkich artykułach?

4:16A teraz wyobraź sobie, że oprócz artykułów mamy filmy i innego rodzaju treści.

4:21I w związku z tym musimy dokonać tej aktualizacji i wewnątrz wszystkich tabel.

4:25Coś takiego, nawet w teorii brzmi bardzo

4:27skomplikowanie, a w przypadku praktyki jest jeszcze bardziej złożone.

4:31W związku z tym w zamian stosujemy nic

4:33innego jak referencję, czyli odniesienie do konkretnego rekordu.

4:37W tym przypadku adres e-mail użytkownika zmieniamy tylko w jednym miejscu i to ma

4:41zastosowanie do wszystkich powiązanych z nim rekordów.

4:44Po prostu w momencie, gdy pobieramy informacje na temat użytkownika i

4:48przypisanych do niego artykułów, nie posługujemy się danymi, które mogą się

4:52zmienić, tylko stałymi identyfikatorami, które ewentualnie możemy ze sobą powiązać.

4:57I teraz co do zasady całość.

5:00Także w momencie, gdy zaprojektujemy sobie całą strukturę bazy i ewentualnie będziemy

5:04ją rozszerzać, bądź też w niektórych sytuacjach modyfikować, to wchodzenie w

5:09interakcje z tymi danymi dostępne jest poprzez język SQL.

5:13W przypadku gdy piszemy polecenia opisujące to, jakie informacje z jakiej

5:18tabeli chcemy pobrać i czy ewentualnie chcemy wykonywać tzw.

5:21join, czyli po prostu łączyć informacje z

5:24innych tabel na podstawie podanej reguły np.

5:27pobierz informacje na temat użytkowników i połącz z wynikami informacje na temat

5:32artykułów w sposób, który do każdego użytkownika przypisze tylko te artykuły,

5:37które pasują identyfikatorem do jego identyfikatora.

5:41W rezultacie otrzymujemy odpowiedź, którą

5:43możemy przesłać do klienta, a następnie wyświetlić ją w interfejsie.

5:48I teraz jeżeli zestawimy to z bazą SQL,

5:51to tam zamiast tabel mamy do czynienia z kolekcjami, wewnątrz których mogą

5:55znajdować się dokumenty, które w przypadku MongoDB są niczym innym jak obiektem

6:00Jackson i z tego powodu MongoDB tak dobrze łączony jest z ekosystemem JavaScriptu.

6:05Ze względu na to, że po prostu mówimy tutaj o tym samym nośniku danych.

6:09Zatem mamy tutaj odzwierciedlone dokładnie takie same informacje jak w przypadku

6:14pierwszego wiersza z tej tabeli, aczkolwiek istnieją tutaj pewne różnice.

6:18Po pierwsze struktura identyfikatora jest

6:20nieco bardziej złożona, ale w obu przypadkach identyfikatory te są

6:24generowane automatycznie przez bazę danych w momencie, gdy dodajemy nowy rekord.

6:29Dzięki temu nie musimy o to dbać, ale jednocześnie możemy z tego korzystać.

6:34Następnie mamy tutaj poszczególne

6:35informacje na temat użytkownika oraz powiązanych z nim artykułów.

6:40Ciekawostką jest jednak to, że w związku z

6:42tym, że nie jesteśmy tutaj ograniczeni w żaden sposób, strukturę tabeli, możemy

6:46zrobić tak, że do tego dokumentu zostaną dopisane kolejne pola, które będą

6:50wykorzystywane tylko w przypadku tego użytkownika.

6:53Jednocześnie jeżeli na pewnym etapie dojdzie do sytuacji, w której inny

6:57użytkownik również będzie potrzebował tych pól, to po prostu je dopiszemy.

7:01I teraz weź pod uwagę fakt, że w momencie

7:04gdy będziemy mieć kolekcję opisującą artykuły, to również sytuacja może

7:08przypominać tutaj posiadanie drugiej tabeli.

7:11Tym bardziej, że odwołujemy się tutaj do tych tabel poprzez identyfikatory.

7:15Zauważ, że identyfikator, który mamy tutaj

7:17wskazuje dokładnie na identyfikator artykułu znajdującego się w tym miejscu.

7:22W związku z tym można tutaj pomyśleć, że mamy do czynienia w zasadzie z tym samym,

7:26aczkolwiek tu mamy tabelę, a tu kolekcja, tu mamy wiersze, a tu dokumenty.

7:30Jednak ta różnica polegająca na tym, że w

7:33tym przypadku wykorzystujemy tabele, a w tym przypadku obiekty, jest zasadniczą

7:37różnicą, która całkowicie zmienia zasady gry.

7:40No bo przykładowo w związku z tym, że

7:42tutaj nie mamy ściśle określonej struktury obiektu, to możemy tutaj dopisywać

7:47informacje bezpośrednio w ramach tego obiektu, zamiast tworzyć dodatkową tabelę.

7:52Przykładem jest mechanizm użytkownika.

7:55Mianowicie zwykle w przypadku, gdy mamy do czynienia z tabelami, musimy utworzyć

7:59oddzielną tabelę Rails, wewnątrz której przechowujemy nazwy pól, a następnie

8:04tworzymy dodatkową tabelę Used Tools, wewnątrz której dokonujemy tak zwanej

8:08relacji wiele do wielu i łączymy wiele różnych ról z wieloma użytkownikami.

8:14W tym przypadku sytuacja jest zdecydowanie prostsza ze względu na to, że wystarczy

8:18dopisać tablicę zawierającą identyfikatory poszczególnych ról.

8:22I teraz pytanie czy nie moglibyśmy

8:24odwzorować tego samego mechanizmu, który mieliśmy w przypadku tabel?

8:28Odpowiedź brzmi oczywiście moglibyśmy, ale nie musimy.

8:32I na tym polega właśnie różnica pomiędzy tymi dwoma rodzajami baz danych.

8:36W jednym przypadku mamy ściśle określoną strukturę.

8:39W drugim przypadku nie mamy żadnych zasad, którymi musimy podążać.

8:43A to, w jaki sposób wyglądają nasze

8:45dokumenty, zależy wyłącznie od potrzeb naszej aplikacji i tego, w jaki sposób

8:50chcemy otrzymywać dostęp do tych informacji.

8:53No bo przykładowo w tym przypadku mamy do

8:55czynienia z tak zwanym budowaniem informacji.

8:58Oznacza to, że wewnątrz jednego dokumentu po prostu osadzane dodatkowe dane.

9:02Natomiast w przypadku artykułów mamy do

9:04czynienia z pretensją, czyli odniesieniem się do innego dokumentu.

9:09I teraz, jeżeli zastanawiasz się, kiedy wykorzystywać kto to jest sposób, no to

9:13odpowiedź jest uzależniona od rodzaju przechowywanych danych.

9:16Przede wszystkim, jeżeli chcesz mieć

9:18bardzo łatwy dostęp do informacji powiązanych z danym dokumentem, to

9:22zdecydowanie lepiej wykorzystać jest embedded.

9:25Jeżeli jednak istnieje potrzeba sięgania

9:27po konkretny dokument niezależnie, to znacznie lepiej jest utworzyć nową

9:32kolekcję, wewnątrz której będziemy je przechowywać.

9:34No bo przykładowo w naszej aplikacji raczej nie będzie potrzeby wyświetlenia

9:38roli admina, ale jednocześnie będzie potrzeba wyświetlania pojedynczego

9:42artykułu, niekoniecznie ze wszystkimi informacjami na temat użytkownika.

9:47Prawda jest taka, że to w jaki sposób

9:48będziemy organizować informacje i łączyć ze sobą dane zależy mocno od naszego

9:53doświadczenia oraz aplikacji, którą rozwijamy.

9:56W jednej z kolejnych lekcji pokażę Ci rodzaje połączeń.

9:59W SQL, jak i nie SQL owej bazie danych i dzięki temu będziesz mieć niezbędne

10:04minimum informacji do tego, aby zacząć projektować własne bazy.