W typowej aplikacji internetowej po stronie serwera współpraca z bazą danych ma logiczną kolejność wynikającą z zależności technicznych między krokami. Najpierw trzeba nawiązać połączenie z serwerem baz danych (np. z użyciem odpowiedniego sterownika). Bez aktywnego połączenia aplikacja nie ma "kanału" komunikacji, więc nie może ani wybrać bazy, ani wysłać zapytania.
Kolejny krok to wybór bazy (lub schematu/kontekstu pracy). W wielu środowiskach jest to jawna operacja, a w innych bywa realizowana przez wskazanie bazy w parametrach połączenia. Sens jest ten sam: zapytania muszą być kierowane do właściwego miejsca.
Dopiero potem wykonuje się zapytanie do bazy (np. SELECT), odbiera wynik i wyświetla dane na stronie WWW poprzez wygenerowanie odpowiedzi HTTP (HTML/JSON). Na końcu następuje zamknięcie połączenia (lub zwolnienie uchwytu/zasobu), co ogranicza zużycie pamięci i liczbę jednoczesnych połączeń.
Dlaczego pozostałe sekwencje są błędne?
- Odpowiedź z "wyborem bazy danych" przed połączeniem jest nielogiczna: nie da się wybrać bazy na serwerze, z którym nie ma się zestawionego połączenia.
- Odpowiedź, w której zapytanie pojawia się przed połączeniem, odwraca zależność: zapytanie jest komunikatem wysyłanym po ustanowieniu kanału komunikacji.
- Odpowiedź zaczynająca od zapytania i pomijająca nawiązanie połączenia oraz wybór bazy to przykład "skrótu procedury" – w praktyce taka sekwencja nie zadziała w aplikacji serwerowej.
Wskazówka egzaminacyjna: sprawdź, czy każdy krok ma spełnione warunki wstępne. Jeśli coś wymaga dostępu do serwera, to najpierw musi istnieć połączenie.
