Bazy danych i usługi danych — interakcja między frontendem a danymi

Strona internetowa, która nic nie pamięta, nie jest warta wiele w praktyce — sklep internetowy musi zapamiętywać zamówienia, forum musi zapamiętywać posty, a login musi pamiętać, kim jesteś. To zadanie bazy danych. Rozporządzenie w sprawie szkolenia programistów sieci web bezpośrednio wskazuje to jako odrębny obszar zawodowy: uczeń powinien być w stanie wyjaśnić interakcję między strukturą bazy danych a frontendem i stosować odpowiednie usługi danych do opracowywania rozwiązań internetowych.

Najczęstszym typem bazy danych w sieci jest baza danych relacyjna. Dane znajdują się w tabelach, gdzie każdy wiersz to jeden rekord, a każda kolumna to określone pole — tabel użytkowników ma na przykład kolumny dla imienia, poczty elektronicznej i daty utworzenia. Każdy wiersz ma klucz podstawowy, unikalny identyfikator, który wskazuje dokładnie na ten rekord. Relacje między tabelami tworzy się za pomocą kluczy obcych: tabela zamówień nie przechowuje ponownie nazwy i adresu klienta, a jedynie identyfikator klienta, który wskazuje wstecz do tabeli klientów. To jest sama idea w relacyjnym — dane są podzielone, ale połączone poprzez klucze.

SQL (Structured Query Language) jest językiem używanym do zapytania relacyjnej bazy danych. Niezależnie od tego, jaki program lub struktura znajduje się pośrodku, prawie zawsze kończy się w tych samych czterech podstawowych działaniach, często zwanych CRUD.

• 01Utwórz — utwórz nowy wpis (SQL: INSERT)
• 02Read — pobierz jeden lub więcej rekordów (SQL: SELECT)
• 03Aktualizacja — naprawić istniejący post (SQL: UPDATE)
• 04Usuń — usuń rekord (SQL: DELETE)

Normalizacja to praca nad strukturyzacją tabel, tak aby te same informacje nie były przechowywane w wielu miejscach niepotrzebnie. Jeśli przechowujesz adres klienta na każdym pojedynczym zamówieniu, wszystkie zamówienia muszą zostać poprawione, jeśli klient się przeprowadzi — a jeśli tego nie robisz konsekwentnie, powstają sprzeczne dane. Zamiast tego, przechowując adres w jednym miejscu i pozwalając zamówieniom wskazywać tam poprzez klucz obcy, prawda istnieje tylko w jednym miejscu. Pobieranie danych kosztuje trochę więcej (musisz "połączyć" tabele), ale wygrywasz znacznie w konsystencji i utrzymaniu.

Nie wszystkie dane dobrze pasują do tabel ze stałymi kolumnami. Bazy danych NoSQL (dokumentowe, klucz/wartość i grafowe są najczęstszymi typami) przechowują dane bardziej elastycznie, często jako dokumenty bez ustalonego szablonu dla każdego pola. Dobrze nadają się do danych, które bardzo się różnią w formie, lub gdy musisz skalować do bardzo dużych ilości zapisów. Bazy danych relacyjne wygrywają, gdy dane mają wyraźne powiązania i potrzebujesz gwarancji, że działanie jest wykonane całkowicie lub wcale nie (transakcje).

Zamiast pisać surowe zapytania SQL wszędzie w kodzie backendu, wielu ludzi korzysta z ORM (Object-Relational Mapper). Pozwala ci pracować z tabelami bazy danych jako zwykłymi obiektami w twoim języku programowania i tłumaczy to na SQL za kulisami. To sprawia, że kod jest łatwiejszy do czytania i mniej podatny na błędy - ale nadal ważne jest zrozumienie, co naprawdę wysyła ORM do bazy danych, szczególnie gdy zapytanie staje się powolne, ponieważ pobiera znacznie więcej danych, niż strona faktycznie potrzebuje.

Usługa danych to warstwa, która udostępnia dane frontendu — typowo interfejs API, który komunikuje się przy użyciu HTTP, jak opisano w artykule o interfejsach API sieci Web. Dostęp do danych powinien być kontrolowany w taki sam sposób jak reszta backendu: tylko uwierzytelnione i autoryzowane wywołania mogą odczytywać lub zmieniać dane, połączenie z bazą danych powinno być chronione logowaniem, które nigdy nie znajduje się w kodzie frontendu, a dane wrażliwe powinny być wysyłane tylko wtedy, gdy jest to naprawdę konieczne dla zadania.

“Baza danych to nie tylko miejsce, w którym dane leżą i czekają — to struktura, która albo Ci pomaga, albo uniemożliwia Ci zaufanie do własnych danych.”

— Zwyczajna reguła nauczycielska w projektowaniu baz danych