W pokazanym kodzie najpierw wykonywane jest zapytanie SQL typu DML:
DELETE FROM produkty WHERE status < 0
Następnie wynik działania operacji jest "mierzony" funkcją mysqli_affected_rows($db). Ta funkcja zwraca liczbę wierszy, które zostały zmienione przez ostatnie zapytanie wykonane na danym połączeniu z bazą (czyli na uchwycie $db).
- Dla DELETE oznacza to liczbę faktycznie usuniętych wierszy spełniających warunek WHERE status < 0.
- Jeżeli żaden rekord nie spełnia warunku, wynik będzie równy 0 (zapytanie wykonało się poprawnie, ale nie usunęło żadnych danych).
- W przypadku błędu wykonania zapytania lub połączenia funkcja może zwrócić -1, co jest sygnałem do sprawdzenia błędu (np. poprzez mechanizmy diagnostyczne MySQLi).
Odpowiedź "Liczby wierszy przetworzonych zapytaniem DELETE FROM" jest poprawna, bo dokładnie opisuje semantykę affected rows dla operacji usuwania.
Pozostałe odpowiedzi są błędne, ponieważ:
- "Liczby wierszy znajdujących się w bazie danych." sugeruje rozmiar bazy lub tabel, a mysqli_affected_rows() nie służy do zliczania wszystkich rekordów.
- "Liczby wierszy dodanych do tabeli produkty." pasowałoby do sytuacji po INSERT, ale tutaj wykonywany jest DELETE, więc nie ma dodawania.
- "Liczby wierszy tabeli produkty, dla których pole status jest większe od zera." myli znak nierówności: zapytanie dotyczy status < 0, a ponadto mysqli_affected_rows() nie liczy rekordów spełniających dowolny warunek, tylko te faktycznie zmienione przez ostatnie zapytanie.
W praktyce taka konstrukcja bywa używana w aplikacjach do komunikatu dla użytkownika, np. "Usunięto X produktów", oraz do rozróżnienia sytuacji: "nie było czego usuwać" (0) od realnego błędu (-1).
