Czym jest baza danych? Przewodnik dla osób budujących aplikacje

Baza danych to uporządkowany zbiór informacji, do którego aplikacja zapisuje i z którego czyta — jej użytkowników, zamówienia, rezerwacje, wiadomości. W odróżnieniu od informacji trzymanych tylko w karcie przeglądarki, dane w bazie zostają po odświeżeniu czy restarcie, a wszyscy korzystający z aplikacji widzą te same rekordy. Większość baz porządkuje dane w tabele, podobne do arkuszy w arkuszu kalkulacyjnym, ale z surowymi regułami, które utrzymują dane w spójności.

Dlaczego to ma znaczenie, gdy budujesz z AI

Najczęstszą niespodzianką przy budowaniu z AI jest aplikacja, która wygląda na gotową, ale zapomina wszystko. Dodajesz klienta, odświeżasz stronę i go nie ma. Zwykle oznacza to, że aplikacja trzymała dane w pamięci przeglądarki, a nie w bazie danych.

Baza danych to także miejsce, w którym mieszka wiele ważnych decyzji, nawet jeśli o tym nie wiesz:

• Co zapisujesz. Jeśli nie przechowujesz statusu rezerwacji, nie pokażesz, które zostały anulowane.
• Jak rzeczy się łączą. Czy jeden klient może mieć wiele rezerwacji, czy jedna rezerwacja wiele usług — to kształtuje całą aplikację.
• Kto co widzi. Większość błędów prywatności dotyczy tego, które rekordy użytkownik może czytać.

Nie musisz sam projektować bazy danych. Ale znajomość podstaw pozwala jasno opisać dane i wcześnie wyłapać problemy.

Codzienna analogia

Wyobraź sobie dobrze zorganizowaną szafę na dokumenty w małym biurze.

Każda szuflada trzyma jeden rodzaj rzeczy: jedna na klientów, jedna na wizyty, jedna na faktury. W każdej szufladzie każda teczka ma ten sam format, z tymi samymi wypełnionymi polami. Każda teczka ma unikalny numer referencyjny, a gdy faktura należy do klienta, teczka faktury zapisuje jego numer zamiast kserować całe jego akta.

To jest baza relacyjna. Szuflady to tabele, teczki to wiersze, pola to kolumny, numery referencyjne to klucze główne, a notatki wskazujące na inną teczkę to klucze obce. Dobry kierownik biura egzekwuje też zasady — żadnej wizyty bez daty, żadnych dwóch klientów z tym samym numerem — tak samo jak baza danych.

Przykład krok po kroku: aplikacja do rezerwacji w salonie

Powiedzmy, że prosisz AI o zbudowanie strony z rezerwacjami dla salonu fryzjerskiego. Rozsądna baza danych miałaby cztery tabele.

services

staff

customers

bookings

Spójrz na tabelę bookings. Nie kopiuje imienia i numeru telefonu Leny do każdej rezerwacji; przechowuje customer_id = 101. Jeśli Lena zmieni numer telefonu, zmienia się on w jednym miejscu, a każda rezerwacja pokazuje nowy. To główna idea relacyjnej bazy danych: zapisz każdy fakt raz i łącz się z nim.

Ta sama struktura odpowiada na użyteczne pytania:

• „Które terminy są wolne u Omara w piątek?” — sprawdź rezerwacje Omara tego dnia.
• „Ile zarobiły koloryzacje w tym miesiącu?” — połącz rezerwacje z usługami i zsumuj ceny.
• „Którzy klienci nie rezerwowali od 90 dni?” — porównaj klientów z ich ostatnią rezerwacją.

Najważniejsze pojęcia

Rodzaje baz danych

Dla niemal wszystkiego, co przedsiębiorca lub mała firma buduje na początek, relacyjna baza danych jest bezpiecznym wyborem domyślnym.

Gdzie baza danych siedzi w aplikacji

Odwiedzający nigdy nie rozmawiają z bazą bezpośrednio. Strona w ich przeglądarce (the frontend) prosi serwer (backend) o dane, zwykle przez API. Serwer sprawdza, kto pyta i czy ma prawo, następnie odpytuje bazę i odsyła tylko to, co dana osoba powinna zobaczyć.

Ten środkowy krok jest ważny. Gdyby przeglądarka mogła odpytywać bazę bezpośrednio z pełnym dostępem, każdy mógłby otworzyć narzędzia deweloperskie i przeczytać wszystko.

Częste błędy i nieporozumienia

• Trzymanie danych tylko w przeglądarce. Pamięć przeglądarki (np. localStorage) żyje na jednym urządzeniu i w jednej przeglądarce. Nadaje się do zapamiętanego filtra, nie do zamówień.
• Wrzucanie wszystkiego do jednej tabeli. Pojedyncza tabela „rezerwacje”, w której imię klienta, telefon i cena usługi są kopiowane do każdego wiersza, szybko się rozjeżdża.
• Przechowywanie haseł jako zwykły tekst. Hasła powinny być hashowane, nigdy zapisane czytelnie. Zobacz czym jest uwierzytelnianie.
• Brak reguł dla danych. Bez wymaganych pól i reguł unikalności dostaniesz rezerwacje bez daty i zduplikowanych klientów.
• Zapominanie o usuwaniu. Zdecyduj, czy usunięcie klienta usuwa jego rezerwacje, zostawia je, czy jest zablokowane.
• Eksperymentowanie na danych produkcyjnych. Ryzykowne zmiany testuj najpierw w bezpiecznym miejscu i trzymaj kopie zapasowe.
• Traktowanie arkusza jako bazy na zawsze. Arkusze świetnie nadają się na start, ale słabo radzą sobie z wieloma jednoczesnymi użytkownikami i uprawnieniami. Zobacz jak zamienić arkusz w aplikację.

O co poprosić kreatora AI

• „Zapisuj to w bazie danych, nie w przeglądarce. Powiedz, jakie tabele utworzysz.”
• „Pokaż schemat w prostej tabeli: każda tabela, jej kolumny i jak się łączą.”
• „Klient może mieć wiele rezerwacji; każda rezerwacja ma dokładnie jedną usługę i jednego pracownika.”
• „Ustaw e-mail klienta jako wymagany i unikalny.”
• „Zablokuj nakładanie się dwóch rezerwacji tego samego pracownika.”
• „Tylko zalogowany właściciel może czytać wszystkie rezerwacje; klienci widzą tylko swoje. Egzekwuj to na serwerze.”
• „Gdy usuwam usługę, nie kasuj przeszłych rezerwacji — zamiast tego oznacz usługę jako nieaktywną.”

Bazy danych w Mythex

Gdy Twoja aplikacja musi zapisywać dane, Mythex dodaje do projektu dedykowaną bazę Postgres — możesz poprosić o to na czacie („zapisuj zapisy na listę oczekujących do bazy danych”) albo użyć polecenia /database. Dane połączenia są automatycznie przekazywane aplikacji, a agent tworzy tabele. Baza usypia się po pięciu minutach bezczynności i budzi przy następnym żądaniu, a w opublikowanej aplikacji płacisz za czas, kiedy była aktywna, z tego samego salda kredytów co przy budowaniu. Jest dostępna w planach Free i Pro. Szczegóły opisuje dokumentacja bazy danych, a szablony aplikacji zawierają gotowe punkty startowe oparte na danych.

Pytania