Projekt „Notatki” – Przetwarzamy dane na backendzie (mongoose)

Kolejny odcinek z serii projekt praktyczny “Notatnik”.  Jest to projekt praktyczny oparty na Node + React + MongoDB. 

W dzisiejszym odcinku pora obsłużyć przetwarzanie danych na backendzie. Dane przechowywane są w MongoDB, więc do połączenia z bazą danych używam mongoose.js

Opis projektu: Dosyć kompleksowo buduję małą aplikację. Tworzę zarówno backend, który łączy się z bazą danych MongoDB. Następnie przez API komunikuje się z frontem zbudowanym na React.js.

Całość pokazuje jak może wyglądać taki projekt, układ plików, konfiguracja, czy jak w ogóle zabrać się do tworzenia full stackowej aplikacji. 

Starałem się pokazywać dobre nawyki i sposoby na organizacje kodu 🙂

Poprzednie odcinki:

odc. 1

odc. 2

odc. 3

SQL vs noSQL | MySQL vs MongoDB – różnice

Niedawno w jednym z odcinków na YT na temat Node.js wspomniałem o tym, że popularnym wyborem dla noda jest mongoDB.

Nie wspomniałem, że mongoDB jest bazą nierelacyjną w przeciwieństwie do poczciwego MySQL, który jest bazą relacyjną.

Prawdopodobnie nie każdy zdaje sobie sprawę co to właściwie oznacza. Czy to tylko 2 wersje tego samego? Absolutnie nie! Różnice są dosyć spore i dzisiaj właśnie o nich.

Poniżej film oraz jeszcze niżej – tekst dla osób preferujących czytanie 

— SQL (RDBMS)

Baza typu SQL tak naprawdę nazywa się bazą typu RDBMS (RElational Database Management System), czyli system zarządzania relacyjną bazą danych. Nazwa SQL jest tak naprawdę uproszczeniem, ponieważ bazy tego typu korzystają z języka SQL (Structured Query Language), czyli strukturyzowanego języka zapytań.

Najpopularniejszym przedstawicielem tej bazy jest poczciwy MySQL (powstały w 1995), od którego większość z nas zaczynała naukę baz.

Struktura

Struktura jest dosyć prosta, główny obiekt to nasza baza danych. Następnie w bazie mamy tabele. Tak jak w zwykłej tabeli, mamy kolumny a w nich wiersze/rekordy. Kolumny opisują jakie dane się w nich znajdują oraz ile ich jest. Każdy wiersz wygląda więc tak samo,i chodzi o jego strukturę.

Cechy

• oczywiście bazy relacyjne posiadają RELACJE, czyli połączenia pomiędzy tabelami (gdybyśmy mieli tabele users i orders, to w zamówieniu umieszczamy jedynie ID użytkownika – tworzymy relacje, zamiast kopiować dane)
• kolejną główną cechą jest użycie języka SQL, w którym piszemy zapytania. Jeśli widziałeś kiedyś kod typu „SELECT id, name FROM users” – to jest właśnie SQL
• dzięki SQLowi możemy tworzyć długie i skomplikowane zapytania, dopiero gotowe zapytanie wysyłane jest do bazy danych i przetwarzane
• Schema – tabele w bazach relacyjnych zawierają KOLUMNY, które to opisują jak wyglądają dane w tej tabeli, to jest właśnie tak zwany Schema, czyli schemat tabeli. Dzięki temu wszystkie wiersze w tabeli są takie same.
• skalowalność wertykalna – oznacza to, że jeśli chcemy wzmocnić naszą bazę musimy wzmocnić jej pojedynczy serwer, dodając np. RAM, mocy procesora lub zwiększając pojemność dysku. Nie możemy dołączyć kolejnego serwera.

— NoSQL

Baza nierelacyjna nazywana jest noSQL, ponieważ nie używa wspomnianego wcześniej języka SQL. Zamiast tego używa JavaScriptu. Powoduje to kilka różnic w samym działaniu takiej bazy, o czym za chwilę.

Struktura

Tak samo, jak przy poprzedniej bazie, podstawowym elementem jest baza danych. Baza danych zawiera tabele, chciałem napisać kolekcje. Chociaż pełnią tę samą rolę. Główna różnica to nazewnictwo, wynikające w kolejnego punktu. Kolekcje zawierają dokumenty. 

W przeciwieństwie do baz relacyjnych, kolekcje nie mają ściśle określonej struktury, dlatego wiersze, tzn. dokumenty mogą wyglądać różnie, mimo że są w tej samej tabeli kolekcji. Dzieje się tak dlatego, że wiersze dokumenty są dokumentem w formacie JSON, a nie wierszem w tabeli.

* powyższe przekreślone pomyłki wykonane są specjalnie, aby lepiej zobrazować czym są kolekcje i dokumenty w porównaniu do tabel i wierszy

Cechy 

• ponieważ nie używa SQLa, zapytania tworzymy w języku JavaScript, jeśli to jest nasze środowisko (lub innym, jeśli pracujemy w innym. MongoDB udostępnia drivery dla wielu języków, co oznacza, że możesz tworzyć zapytania w swoim języku)
• jak mówi sama nazwa, taka baza nie ma relacji – oznacza to, że kolekcje nie są ze sobą w żaden sposób połączone. Może to powodować duplikowanie danych. 
• brak Schema (lub dynamiczny Schema) – kolekcje nie mają „kolumn”, czyli nie mają określonej struktury, dlatego dokumenty mogą się różnić, mimo że są w tej samej kolekcji
• skalowalność horyzontalna i wertykalna
• szybkość działania – mongoDB jest znacznie szybsza niż mySQL, szczególnie widoczne przy big data

Co jest lepsze? 

Jak zawsze odpowiedź na to pytanie jest jedna: to zależy. 

Baza nierelacyjna noSQL działa szybciej oraz jest skalowalna horyzontalnie co pozwala na pracę z big data. 

Baza relacyjna (SQL) zapewnia większą integralność danych (dzięki Schema) oraz relacje.

W zależności od projektu możesz potrzebować innych cech.