Wskaż zapytanie SQL tworzące użytkownika sekretarka na localhost z hasłem zaq123
A. CREATE USER 'sekretarka'@'localhost' IDENTIFIED `zaq123`;
B. CREATE USER `sekretarka`@`localhost` IDENTIFY BY `zaq123`;
C. CREATE USER `sekretarka`@`localhost` IDENTIFIED BY 'zaq123';
D. CREATE USER `sekretarka`@`localhost` IDENTIFY "zaq123";
Pytanie z egzaminu CKE, czerwiec 2021 (arkusz E.14-SG-21.06).
Polecenie CREATE USER `sekretarka`@`localhost` IDENTIFIED BY 'zaq123'; ma poprawną składnię dla MySQL/MariaDB, bo używa konstrukcji CREATE USER nazwa_użytkownika@host IDENTIFIED BY 'hasło'. Część `sekretarka`@`localhost` oznacza konto użytkownika sekretarka, które może logować się tylko z hosta lokalnego, czyli z tej samej maszyny, na której działa serwer bazy danych. To jest ważne praktycznie: taki użytkownik nie zaloguje się z innego komputera w sieci, co trochę poprawia bezpieczeństwo. Słowa IDENTIFIED BY informują serwer, że podajemy metodę uwierzytelniania przez hasło, a samo hasło jest zapisane jako literał tekstowy w apostrofach: 'zaq123'. Backticki, czyli znaki `...`, stosuje się zwykle do nazw identyfikatorów, np. nazw tabel, kolumn albo tu części konta, natomiast hasło powinno być tekstem, więc apostrofy są dobrym wyborem. W praktyce po utworzeniu użytkownika zwykle wykonuje się jeszcze GRANT, np. nadanie tylko potrzebnych uprawnień do konkretnej bazy. Moim zdaniem warto zapamiętać schemat: najpierw CREATE USER, potem GRANT, a na końcu kontrola uprawnień. Dobra praktyka branżowa to nie dawać od razu ALL PRIVILEGES, jeśli użytkownik ma tylko wykonywać konkretne zadania, oraz używać mocniejszych haseł niż zaq123, bo takie hasło jest raczej pokazowe i w prawdziwym systemie byłoby słabe.
W tym pytaniu łatwo pomylić kilka podobnych elementów składni SQL, szczególnie jeśli ktoś zapamiętał sens polecenia, ale nie dokładne słowa kluczowe. W MySQL poprawna forma tworzenia konta z hasłem opiera się na zwrocie IDENTIFIED BY, a nie na samym IDENTIFY. To nie jest drobna literówka stylistyczna, tylko konkretne słowo kluczowe rozpoznawane przez parser SQL. Serwer oczekuje pełnej konstrukcji informującej, że użytkownik jest identyfikowany podanym hasłem. Jeśli wpisze się IDENTIFY, zapytanie zostanie potraktowane jako niepoprawne składniowo. Druga częsta pułapka dotyczy znaków cytowania. Backticki `...` w MySQL służą głównie do cytowania identyfikatorów, czyli nazw obiektów bazy danych, na przykład tabel, kolumn, baz albo czasem elementów nazwy konta. Hasło nie jest identyfikatorem, tylko wartością tekstową, dlatego powinno być zapisane jako literał znakowy, najczęściej w apostrofach. Użycie `zaq123` sugeruje nazwę identyfikatora, a nie tekst hasła, i to prowadzi do błędnej interpretacji składni. Podobnie konstrukcja IDENTIFIED `zaq123` pomija wymagane BY, więc mimo że wygląda blisko poprawnej wersji, nadal nie spełnia reguł polecenia CREATE USER. Z mojego doświadczenia uczniowie często patrzą tylko na to, czy występuje nazwa użytkownika, localhost i hasło, a SQL niestety jest dość wymagający co do kolejności oraz rodzaju cudzysłowów. W administracji bazami danych takie szczegóły mają znaczenie, bo źle zapisane polecenie albo nie wykona się wcale, albo stworzy konto inaczej niż planowano. W realnym środowisku trzeba też pamiętać, że samo utworzenie użytkownika nie daje mu jeszcze sensownych uprawnień do pracy z bazą; do tego służy osobne GRANT, najlepiej zgodne z zasadą minimalnych uprawnień.