Właściwym zestawem kroków według kolejności, które należy wykonać w celu nawiązania współpracy między aplikacją internetową po stronie serwera a bazą SQL, jest
A. wybór bazy, zapytanie do bazy, nawiązanie połączenia z serwerem baz danych, wyświetlenie na stronie WWW, zamknięcie połączenia.
B. nawiązanie połączenia z serwerem baz danych, wybór bazy, zapytanie do bazy - wyświetlane na stronie WWW, zamknięcie połączenia.
C. wybór bazy danych, nawiązanie połączenia z serwerem baz danych, zapytanie do bazy - wyświetlane na stronie WWW, zamknięcie połączenia.
D. zapytanie do bazy, wybór bazy, wyświetlenie na stronie WWW, zamknięcie połączenia.
Pytanie z egzaminu CKE, styczeń 2018 (arkusz E.14-X-18.01).
W tej sytuacji właściwa kolejność to: najpierw nawiązanie połączenia z serwerem baz danych, potem wybór konkretnej bazy, następnie wykonanie zapytania SQL i wykorzystanie wyniku do wygenerowania treści strony WWW, a na końcu zamknięcie połączenia. Tak właśnie działa typowa aplikacja serwerowa, np. napisana w PHP z mysqli albo PDO. Serwer WWW uruchamia skrypt, skrypt łączy się z serwerem MySQL/MariaDB, wskazuje bazę danych, wykonuje zapytanie typu SELECT, INSERT albo UPDATE, przetwarza wynik i dopiero wtedy buduje HTML zwracany do przeglądarki. Moim zdaniem to jedna z podstawowych rzeczy, które warto sobie dobrze poukładać, bo potem łatwiej zrozumieć błędy typu brak połączenia, nie wybrano bazy danych albo zapytanie zwraca pusty wynik. W praktyce dobrą branżową praktyką jest też obsługa wyjątków, sprawdzanie błędów połączenia, używanie zapytań przygotowanych, czyli prepared statements, oraz zamykanie zasobów, szczególnie gdy aplikacja wykonuje dużo operacji na bazie. Samo wyświetlenie danych na stronie nie jest osobnym etapem pracy bazy, tylko skutkiem poprawnie wykonanego zapytania i przetworzenia wyniku po stronie serwera.
W komunikacji aplikacji internetowej z bazą SQL bardzo ważna jest kolejność działań, bo serwer baz danych nie wykona sensownie operacji, jeżeli aplikacja nie ma jeszcze aktywnego połączenia. Częsty błąd polega na myśleniu, że można najpierw wysłać zapytanie albo wybrać bazę danych, a dopiero później połączyć się z serwerem. Technicznie to nie ma sensu: zapytanie SQL musi zostać przesłane przez istniejące połączenie, a wybór bazy również odbywa się w kontekście sesji połączenia z serwerem MySQL, PostgreSQL czy innym systemem RDBMS. Bez tego aplikacja nie wie, gdzie ma wysłać polecenie i z jakich zasobów korzystać. Innym nieporozumieniem jest umieszczanie wyboru bazy przed nawiązaniem połączenia. Sama nazwa bazy, np. sklep albo szkola, nie wystarczy, bo najpierw trzeba podać host, użytkownika, hasło, port i dopiero po poprawnym uwierzytelnieniu można pracować na konkretnej bazie. Warto też zauważyć, że wyświetlenie danych na stronie WWW nie zastępuje zapytania do bazy. Strona pokazuje wynik pracy skryptu serwerowego, a nie komunikuje się bezpośrednio z SQL-em, przynajmniej w klasycznym modelu PHP + MySQL. Z mojego doświadczenia uczniowie czasem mieszają logikę interfejsu z logiką backendu: widzą tabelę na stronie i zakładają, że to jest jeden krok razem z wyborem bazy. Poprawny przepływ jest jednak bardziej uporządkowany: połączenie, wybór bazy, zapytanie, przetworzenie wyniku, prezentacja użytkownikowi i zwolnienie zasobów. To jest też zgodne z dobrymi praktykami, bo pozwala łatwiej diagnozować błędy, zabezpieczać zapytania oraz kontrolować obciążenie serwera.