Szeroka Perspektywa Full-Stack Web Developmentu: Najczęściej popełniane błędy

0:00W momencie, gdy będziesz projektować bądź.

0:02Nawet pracować z bazami danych,

0:04niewykluczone, że spotkasz kilka powtarzających się problemów.

0:07Z tego powodu zebrałem całą listę

0:09problemów, z którymi ja sam się spotykałem.

0:12A nawet pewnych błędów, które ja sam popełniałem bądź miałem.

0:15Do czynienia z ich konsekwencjami. Jednym z takich.

0:18Fundamentalnych problemów, które.

0:20Można spotkać w bazach danych jest nie wykorzystywanie.

0:23Typów. Tak jak już mówiłem, każda kolumna w danej

0:26tabeli czy właściwość w dokumencie powinny mieć.

0:29Przypisany typ oraz dodane ograniczenia, takie jak np.

0:33maksymalna. Długość.

0:34Jednocześnie musisz wiedzieć, że takie ograniczenia.

0:37Narzucane są na etapie projektowania

0:39struktury bazy oraz na etapie projektowania z.

0:42Kimś bądź modeli.

0:43Mianowicie przykładowo mamy tutaj. Dokumentację.

0:46PRISM, gdzie możemy spotkać dokładnie modele, wewnątrz których.

0:50Określamy dostępne pola.

0:51I jak widzisz zaznaczamy.

0:53Nie tylko ich typ, ale również dodatkowe

0:55właściwości, takie jak chociażby domyślne pola.

0:58Czy np. określenie, że w przypadku użytkowników.

1:01E-mail musi być unikatowe.

1:03Teoretycznie przecież nic nie stoi na.

1:04Przeszkodzie, aby w momencie rejestrowania użytkowników.

1:08Po prostu dbać. O to, aby nie.

1:09Umożliwić rejestracji na ten sam. Email.

1:12Jednocześnie z różnych powodów może zdarzyć się tak, że.

1:15Pojawi.

1:15Się sposób dodawania użytkowników w Twojej aplikacji, w.

1:18Której nie będzie to weryfikowane.

1:20Wtedy taka sytuacja powinna być

1:22przechwycona bezpośrednio przez silnik bazodanowy.

1:25Który nie dopuści do dodania rekordu, który.

1:28Nie pasuje do tych ograniczeń. Z tego.

1:30Powodu miej.

1:31Na uwadze fakt, że zarówno w przypadku SQL.

1:34Owych, jak i nowa SQL owych baz danych musisz dokładnie określić to, jak będzie

1:38wyglądał model oraz jakie właściwości będzie posiadać.

1:41Dodatkowo, w przypadku gdy zajdzie potrzeba, aby pomiędzy tabelami.

1:45Bądź. Kolekcjami istniały jakieś powiązania, to.

1:48One.

1:48Również zwykle opisywane są na etapie dema, czyli w tym przypadku Object.

1:53Bądź ewentualnie. Primy.

1:55Zwróć uwagę, że mamy tutaj post, a następnie mamy autora, w przypadku którego

1:59wyraźnie jest zaznaczona relacja oraz sposób powiązania tych pól.

2:04Konkretnie tutaj mamy informację o tym, że wewnątrz posta znajduje.

2:07Się autor ID.

2:08Który jest Integer

2:10wskazujący na identyfikator pochodzący z modelu User, a konkretnie z kolumny ID.

2:16Jeżeli chodzi o.

2:17Relacje, tutaj również potrzebujesz trochę praktyki.

2:19Aby odnaleźć się w tych regułach definiowania.

2:22Powiązań. Natomiast na koniec dnia jest to

2:24stosunkowo proste i przede wszystkim intuicyjne.

2:27Kolejnym błędem poza brakiem typów czy też

2:30w ogóle ich nie określania jest ich niewłaściwe określenie.

2:33Przykładowo dobrze jest określać typ

2:36kolumny i narzucać na nią określone ograniczenia, takie jak np.

2:40długość znaków.

2:41Ale jednocześnie w momencie, gdy próbujemy być tutaj zbyt kreatywni, może dojść.

2:45Do sytuacji, w której.

2:46Na rzucimy ograniczenie, które w.

2:48Niektórych sytuacjach może okazać się zbyt.

2:50Duże i doprowadzić do błędów.

2:52No bo teoretycznie sytuacja, w której ktoś

2:54ma adres e-mail dłuższy niż 64 znaki raczej zdarza się dość rzadko, aczkolwiek

2:59nie można powiedzieć, że taka sytuacja nie jest możliwa.

3:02W momencie, gdy do niej dojdzie.

3:04Nasza aplikacja nie umożliwi np.

3:06zarejestrowania takiego.

3:07Konta, a to będzie wymagało.

3:09Od nas wprowadzania dodatkowych zmian.

3:11Oczywiście muszę tutaj zaznaczyć, że ten

3:13przykład jest tylko pokazowy, ale takich błędów dotyczących nieprawidłowego.

3:17Określenia typu bądź jakichś ograniczeń. Jest naprawdę.

3:20Dużo i łatwo się na nie natknąć.

3:22Kolejnym rodzajem błędów jest niewłaściwa bądź całkowity brak normalizacji.

3:27Inaczej mówiąc, nasza baza zaprojektowana jest tak, że.

3:30Wiele danych powtarza się.

3:32Na przestrzeni tych samych. Tabel, bądź.

3:34Też co gorsza, występują w wielu różnych miejscach.

3:37I to niesamowicie utrudnia pracę z nimi oraz np.

3:40aktualizowanie.

3:41No bo dla przykładu, jeżeli mamy tutaj

3:43użytkowników, do których przypisane są tagi.

3:46Teoretycznie wszystko jest w porządku, ale po pierwsze za każdym razem, gdy.

3:49Będziemy chcieli wyświetlić te tagi, no to mamy.

3:52Problem z dostępem do każdego z nich.

3:54Ze względu na to, że znajdują się one w

3:56jednej kolumnie, a dodatkowo są oddzielone przecinkami.

3:59Oznacza to, że za każdym razem.

4:01Gdy będziemy chcieli je pobrać, będziemy

4:03musieli je podzielić i to samo będziemy musieli.

4:06Zastosować. W momencie, gdy będziemy dodawać nowy.

4:08Tak. Coś takiego nie ma najmniejszego sensu.

4:11W związku z tym. Zdecydowanie lepiej.

4:13Jest wykorzystać.

4:14Dodatkową tabelę. Poza tym np.

4:16w momencie, gdy w jakimś tagu.

4:17Pojawi się literówka, bądź też zajdzie potrzeba jego zmiany.

4:20W tej konkretnej sytuacji wykonanie takiej operacji jest naprawdę bardzo złożone.

4:25Z tego powodu warto zadbać.

4:27O to, aby dane w naszej bazie nie powtarzały się, aczkolwiek ta reguła.

4:31Nie ma aż takiego zastosowania w przypadku relacyjnych.

4:34Baz danych, gdzie ewentualne.

4:35Powtórzenia są nieco bardziej.

4:37Dopuszczalne, aczkolwiek również trzeba wziąć pod uwagę np.

4:40możliwość globalnego.

4:42Aktualizowania jakiś informacji.

4:44I teraz następnym problemem, z którym

4:46również bardzo często się spotykam jest brak spójności oraz brak indeksów.

4:51O indeksach już mówiłem, że w przypadku każdej z tabel warto je stosować.

4:55Natomiast jeżeli chodzi o spójność.

4:57Mam tutaj na myśli takie elementy jak chociażby.

5:00Wielkie i małe. Litery w nazwach, stosowanie polskiego czy

5:03angielskiego lub też nawet wykorzystywanie liczby mnogiej oraz pojedynczej.

5:07W moim przypadku. Stosuje się raczej do ogólnie przyjętych

5:10konwencji, które narzucane są przez technologię, z której aktualnie korzystam,

5:14albo po prostu są spójne z przyjętą konwencją w ramach danego.

5:18Projektu.

5:19Ogólną zasadą jest tutaj to, że istnieją oczywiście różne strategie nazewnictwa

5:23oraz organizacji informacji w bazach danych.

5:26Natomiast według. Mnie.

5:27Bez większego ocenienia, która z technik

5:29jest lepsza, która gorsza, warto po prostu zdecydować.

5:32Się na jedną i bardzo się jej trzymać.

5:35Naturalnie w niektórych przypadkach będą konieczne jakieś odstępstwa.

5:38Natomiast co do zasady brak spójności

5:40bardzo utrudnia późniejszą pracę z takim projektem.

5:44No i teraz ostatnim, aczkolwiek chyba

5:46najtrudniejsze do uniknięcia wątkiem są różnego rodzaju błędne decyzje projektowe.

5:51Mianowicie wyobraźmy sobie sytuację, w

5:53której mamy użytkowników oraz mamy jakieś społeczności.

5:56Następnie ci użytkownicy mogą tworzyć

5:59grupy, więc występuje tutaj powiązanie pomiędzy tabelą groups i users.

6:03Teoretycznie nie ma w tym nic złego, w końcu to użytkownicy tworzą grupę.

6:08Jednocześnie te grupy występują w ramach społeczności.

6:11Oznacza to, że jeżeli jakaś społeczność

6:13przypisana jest do wybranej grupy, która to została utworzona przez konkretnego

6:18użytkownika, to teoretycznie może dojść do sytuacji, w której użytkownik usuwa konto,

6:23a wraz z nim kaskadowo mogą być usunięte wszystkie powiązane z nim grupy i tym

6:27samym wszystkie powiązane z tymi grupami społeczności.

6:31Jest to bez wątpienia bardzo zła decyzja

6:33projektowa, którą pozornie można bardzo łatwo naprawić.

6:36Mianowicie, jeżeli użytkownicy będą mieć

6:39możliwość tworzenia grup, to przede wszystkim możemy.

6:42W ogóle. Nie uwzględniać informacji o tym, kto daną

6:44grupę utworzył i po prostu przypisać ją do społeczności, bądź też na etapie

6:48projektowania bazy danych zaznaczyć, że pole User ID może być NULL.

6:53I tym samym w momencie gdy usuniemy.

6:55Użytkownika i zniknie nam pole User.

6:57ID, to nadal w.

6:58Takiej sytuacji grupa zostaje i tym samym też powiązana z nią społeczność.

7:02Pomińmy już tutaj fakt, czy takie

7:04powiązanie w ogóle ma sens, natomiast chodzi mi tutaj o to, że należy

7:08przewidywać różne możliwe sytuacje i również te związane np.

7:12z usuwaniem informacji z bazy, bądź też jakiegoś rodzaju ich modyfikacjami.

7:17Tak jak powiedziałem, unikanie.

7:18Takich problemów jest niemal niemożliwe i przede wszystkim wynika z naszego

7:22doświadczenia oraz tego, jak dobrze znamy kontekst biznesowy.

7:26No bo na tej podstawie będziemy.

7:28Projektować struktury, które będą funkcjonować w naszej aplikacji.

7:31Oczywiście sam fakt tego.

7:33Że trudno jest uniknąć tego rodzaju błędów, nie.

7:35Upoważnia nas do. Tego, aby ich unikać.

7:38Tym bardziej powinniśmy poświęcić

7:39wystarczająco dużo uwagi, aby zminimalizować ryzyko ich wystąpienia.

7:44Ze względu na to, że jeżeli wyobrazisz sobie, że mamy tutaj np.

7:47100 tysięcy użytkowników. I kilkanaście.

7:50Tysięcy grup i kilka społeczności, to w niektórych sytuacjach wprowadzenie

7:54jakiejkolwiek zmiany w architekturze może stanowić dość duże wyzwanie.

7:58Zatem jeżeli.

7:59Chodzi o takie najczęściej popełniane błędy w kontekście projektowania baz

8:03danych, to by było na tyle, jeżeli chodzi o tę.

8:05Najważniejszą listę. Pamiętaj oczywiście.

8:08Że te wszystkie wątki znacząco mogą się

8:10rozwijać i różnić w zależności od wybranej bazy danych oraz zestawu technologii,

8:14które wykorzystasz do projektowania swojej aplikacji.

8:17Natomiast ogólne zasady dotyczące typów normalizacji, spójności oraz podejmowania.

8:23Mądrych decyzji projektowych wydaje mi się.

8:25Że są wspólne dla każdego rodzaju projektu.

8:28I tutaj jeszcze na koniec odsyłam.

8:29Cię do artykułu na blogu technologii MongoDB.

8:33Gdzie możesz przeczytać o wzorcach projektowania bazy.

8:35Danych opartej o MongoDB.

8:37Mianowicie masz tutaj nie tylko.

8:39Listę wzorców oraz ich zalet oraz wad, ale

8:42też sytuacje, w których mogą Ci się konkretnie sprawdzić.

8:45Mogę tutaj tylko powiedzieć, że stopniowe rozszerzanie swojej wiedzy na temat

8:49projektowania baz danych i wykorzystywania różnego rodzaju technik z pewnością jest

8:53tutaj dobrym pomysłem ze względu na to, że nawet jeżeli.

8:56Nie będziesz w sytuacji, gdzie będziesz.

8:58Projektować jakąś aplikację od całkowitych

9:00podstaw, tak jednocześnie znajomość tych wszystkich wzorców pomoże Ci w ich.

9:04Rozwoju i ewentualnie unikania jakiś

9:07przyszłych błędów, z których w danej chwili.

9:09Nikt nie zdaje sobie sprawę. No i w tym.

9:12Momencie zbliżyliśmy się już do końca tej lekcji.

9:14Więc dziękuję Ci za uwagę. I zapraszam do.

9:16Kolejnej.