Jak dodać bazę danych do aplikacji (bez utraty danych później)

Aby dodać bazę danych do aplikacji, wybierz zarządzaną relacyjną bazę danych (zwykle Postgres), trzymaj jej ciąg połączenia w sekrecie po stronie serwera, utwórz jedną tabelę dla każdego rodzaju rzeczy, które aplikacja przechowuje, i spraw, by to twój backend — nigdy przeglądarka — odczytywał i zapisywał dane. Jeśli budujesz w narzędziu AI, zwykle wystarczy napisać „zapisz to w bazie danych”, a agent przygotuje tabele i kod. Twoje zadanie to jasno opisać dane i sprawdzić, czy naprawdę się zapisują.

Ten przewodnik opisuje, kiedy potrzebujesz bazy danych, główne opcje, jak opisać swoje dane i błędy, które prowadzą do utraty lub wycieku danych.

Kiedy aplikacja potrzebuje bazy danych

Baza danych jest potrzebna, gdy aplikacja ma zapamiętać coś po zamknięciu strony albo udostępnić dane wielu osobom. Typowe sygnały:

• Odwiedzający coś wysyłają: formularz, rejestrację, rezerwację, zamówienie
• Użytkownicy mają konta z własnymi zapisanymi treściami
• Administrator musi widzieć lub edytować to, co stworzyli inni
• Chcesz raporty lub liczniki w czasie

Nie potrzebujesz bazy dla statycznej strony, na której wszyscy widzą tę samą treść, na przykład portfolio czy prostej strony lądowania. Jeśli nie wiesz, czym właściwie jest baza danych, najpierw przeczytaj czym jest baza danych.

Twoje opcje

Dla większości małych i średnich aplikacji webowych właściwym domyślnym wyborem jest relacyjna baza, jak Postgres. Dobrze radzi sobie z powiązaniami (klient ma wiele zamówień), utrzymuje spójność danych i pozwala później odpowiadać na pytania za pomocą SQL. Krótkie wyjaśnienie znajdziesz w czym jest Postgres.

Opisz dane przed budową

Najbardziej przydatne, co możesz zrobić, to spisać rzeczy, które aplikacja przechowuje, i jak się ze sobą łączą. Nie potrzebujesz żargonu bazodanowego. Dla aplikacji rezerwacji:

• Klienci: imię i nazwisko, e-mail, telefon
• Usługi: nazwa, czas trwania, cena
• Rezerwacje: który klient, która usługa, godzina rozpoczęcia, status (oczekująca, potwierdzona, anulowana)

To trzy tabele. „Który klient” i „która usługa” stają się powiązaniami (kluczami obcymi) między nimi. Dobre ustalenie tego na początku ma znacznie większe znaczenie niż wybór technologii, bo zmiana kształtu danych, które już mają prawdziwe wiersze, jest trudniejsza niż zmiana układu strony.

Kilka zasad kciuka:

• Jedna tabela dla każdego rodzaju rzeczy. Nie upychaj zamówień w tekstowej kolumnie w kliencie.
• Każdy wiersz ma ID i czas utworzenia. Oba przydadzą się później.
• Używaj właściwych typów. Daty jako daty, pieniądze jako pełne grosze lub typ dziesiętny, nie jako tekst.
• Oznaczaj pola wymagane jako wymagane. Niech baza odrzuca złe dane, a nie tylko formularz.

Przykładowe prompty

Zacznij od jednej funkcji naraz, zamiast wrzucać cały schemat:

Dodaj bazę danych do tej aplikacji. Utwórz tabelę rezerwacji z imieniem i nazwiskiem klienta, e-mailem, usługą, godziną rozpoczęcia i statusem (oczekująca, potwierdzona, anulowana; domyślnie oczekująca). Zapisuj zgłoszenia z formularza rezerwacji, pokaż komunikat o sukcesie i dodaj stronę administratora, która wyświetla rezerwacje od najnowszej.

Potem rozbuduj:

Dodaj tabelę usług (nazwa, czas trwania w minutach, cena w groszach). Zamień dowolne pole tekstowe z usługą w rezerwacjach na powiązanie z tabelą usług i przenieś istniejące rezerwacje bez ich usuwania.

I zabezpiecz:

Upewnij się, że wszystkie odczyty i zapisy do bazy odbywają się po stronie serwera. Przeglądarka nigdy nie może otrzymać ciągu połączenia z bazą. Zweryfikuj e-mail i godzinę rozpoczęcia po stronie serwera przed wstawieniem do bazy.

Krok po kroku

1. Spisz swoje dane jak wyżej: rzeczy, pola, powiązania między nimi.
2. Utwórz bazę. W narzędziu AI poproś o nią w czacie. Gdzie indziej załóż zarządzany Postgres i skopiuj jego ciąg połączenia.
3. Zapisz ciąg połączenia jako sekret (zmienną środowiskową na serwerze), nigdy w kodzie. Zobacz zmienne środowiskowe i sekrety.
4. Utwórz tabele. Użyj migracji, czyli wersjonowanych skryptów zmieniających schemat, aby zmiany były powtarzalne i możliwe do cofnięcia.
5. Zbuduj trasy serwerowe, które tworzą, odczytują, aktualizują i usuwają wiersze (CRUD). Przeglądarka wywołuje te trasy; nigdy nie łączy się z bazą bezpośrednio.
6. Podłącz interfejs do tych tras: formularze, które zapisują, listy, które się ładują, stany pustej listy, gdy nie ma jeszcze danych.
7. Sprawdź trwałość. Wyślij coś, przeładuj stronę, otwórz ją w innej przeglądarce. Jeśli danych nie ma, nie zostały zapisane w bazie.
8. Sprawdź dostęp. Zaloguj się jako drugi użytkownik i upewnij się, że nie widzisz ani nie edytujesz danych pierwszego.
9. Opublikuj, potem przetestuj ponownie na żywym adresie, bo opublikowana aplikacja może używać innego połączenia niż podgląd.

Typowe błędy

• Zapisywanie w przeglądarce i założenie, że to zapisane. localStorage działa, dopóki ktoś nie otworzy aplikacji na innym urządzeniu. Zawsze testuj w drugiej przeglądarce.
• Ciąg połączenia w kodzie frontendowym. Każdy może przeczytać kod frontendu. To daje mu całą twoją bazę.
• Brak kontroli dostępu. „Pokaż moje zamówienia” musi filtrować po zalogowanym użytkowniku na serwerze, a nie w interfejsie. To najczęstsza dziura bezpieczeństwa w aplikacjach budowanych przez AI; nasza lista kontrolna bezpieczeństwa opisuje to szczegółowo.
• Destrukcyjne zmiany schematu. Prośba o „zmianę nazwy tabeli” lub „zmianę struktury” może ją usunąć i utworzyć na nowo. Gdy istnieją prawdziwe dane, napisz: „przenieś istniejące wiersze, niczego nie usuwaj”.
• Pliki przechowywane w bazie. Obrazy i PDF-y należą do magazynu plików, a w tabeli zapisuje się tylko ich adres lub klucz. Zobacz jak dodać przesyłanie plików.
• Brak kopii zapasowych. Zanim będziesz mieć klientów, poznaj sposób, w jaki platforma wykonuje kopie i jak je przywrócić.

Lista kontrolna

• Każdy rodzaj rzeczy ma własną tabelę z ID i czasem utworzenia
• Pola wymagane i typy są egzekwowane przez bazę
• Ciąg połączenia istnieje tylko w sekretach po stronie serwera
• Wszystkie odczyty i zapisy przechodzą przez trasy serwerowe
• Każdy użytkownik może czytać i zmieniać tylko swoje wiersze
• Dane przetrwają przeładowanie i są widoczne w innej przeglądarce
• Zmiany schematu używają migracji i zachowują istniejące wiersze
• Wiesz, jak działają kopie zapasowe i przywracanie
• Opublikowana aplikacja została przetestowana na żywo

Dodawanie bazy danych w Mythex

W Mythex każdy projekt może dostać własną dedykowaną bazę Postgres, zarówno w planie Free, jak i Pro. Zwykle nie musisz klikać osobnego przycisku „podłącz”: poproś w czacie (np. „zapisuj adresy e-mail z listy oczekujących w bazie danych”) lub wpisz /database. Dane połączenia zostaną wstrzyknięte do przestrzeni roboczej i do opublikowanej aplikacji. Ustawienia projektu pokazują, czy baza jest aktywna.

Baza przechodzi w stan uśpienia po 5 minutach bezczynności i budzi się przy następnym żądaniu. Użycie opublikowanej aplikacji jest naliczane za czas, w którym baza faktycznie działała, z tego samego salda kredytów, którego używasz do budowania. Jeśli dodasz bazę po publikacji, opublikuj ponownie, aby działająca aplikacja ją uwzględniła.

Zobacz Database oraz przepis Build a CRUD app w dokumentacji. Część dotyczącą logowania w kontekście danych per użytkownik znajdziesz w jak dodać logowanie do aplikacji.

Pytania