Pole insert_id zdefiniowane w bibliotece MySQLi języka PHP może być wykorzystane do
A. otrzymania id ostatnio wstawionego wiersza.
B. pobrania najwyższego indeksu bazy, aby po jego inkrementacji wstawić pod niego dane.
C. otrzymania kodu błędu, gdy proces wstawiania wiersza się nie powiódł.
D. pobrania pierwszego wolnego indeksu bazy, tak, aby można było pod nim wstawić nowe dane.
Pytanie z egzaminu CKE, czerwiec 2021 (arkusz EE.09-SG-21.06).
Pole insert_id w MySQLi służy do odczytania identyfikatora ostatniego wiersza wstawionego do tabeli, o ile tabela ma kolumnę z mechanizmem AUTO_INCREMENT. W praktyce używa się tego zaraz po poprawnym wykonaniu zapytania INSERT, np. gdy dodajesz nowego użytkownika, zamówienie albo wpis w tabeli głównej i potem musisz dopisać powiązane rekordy w innych tabelach. Typowy scenariusz: aplikacja zapisuje zamówienie, pobiera insert_id, a następnie używa tego ID jako klucza obcego przy dodawaniu pozycji zamówienia. To jest normalna i dobra praktyka, bo nie trzeba samemu zgadywać numeru rekordu. Moim zdaniem to jedna z tych rzeczy w PHP i SQL, które naprawdę warto rozumieć praktycznie, nie tylko z definicji. Ważne jest też, że insert_id nie zwraca kodu błędu ani nie wyszukuje wolnych identyfikatorów. Błędy obsługuje się przez errno, error albo wyjątki, a generowanie identyfikatorów zostawia się bazie danych. Dzięki temu aplikacja jest bezpieczniejsza przy wielu jednoczesnych użytkownikach i mniej podatna na dziwne konflikty danych.
Właściwość insert_id z biblioteki MySQLi bywa mylona z kilkoma innymi mechanizmami, ale jej zadanie jest dość konkretne: zwraca identyfikator ostatnio wstawionego rekordu wygenerowany przez AUTO_INCREMENT. Nie jest to miejsce do pobierania kodu błędu po nieudanym INSERT. Do diagnostyki błędów w MySQLi służą inne elementy, na przykład errno, error albo obsługa wyjątków, zależnie od konfiguracji. Jeśli zapytanie się nie powiedzie, poprawny program powinien najpierw sprawdzić wynik wykonania zapytania i odpowiednio zareagować, a nie zakładać, że insert_id poda informację o awarii. Częsty błąd myślowy polega też na traktowaniu identyfikatora jako czegoś, co programista powinien sam obliczać przez pobranie najwyższego numeru i dodanie 1. To jest niebezpieczne, szczególnie w aplikacjach webowych, gdzie kilku użytkowników może w tym samym momencie dodawać dane. Wtedy łatwo o kolizje, niespójność albo błędy klucza głównego. Podobnie nie szuka się pierwszego wolnego indeksu w tabeli. W bazach relacyjnych identyfikator nie musi być ciągły; po usunięciach rekordów mogą powstać luki i to jest całkiem normalne. Dobra praktyka jest taka, żeby za nadawanie kluczy głównych odpowiadał silnik bazy danych, a aplikacja tylko odczytywała wynik, gdy jest jej potrzebny. Z mojego doświadczenia takie podejście oszczędza naprawdę dużo problemów przy późniejszej rozbudowie systemu.