#140Baze de date

Baze de date FOOD_DELIVERY — ștergerea comenzilor anulate și numărul lor pe restaurant

deleteselect afisare →agregategruparefiltrarejonctiuni

Enunț

Baza de date FOOD_DELIVERY conține informații despre restaurante și comenzile plasate la acestea. Un restaurant poate avea mai multe comenzi.

Tabelul	Structura
`Restaurante`	`idr` number(3), `nume` varchar2(60), `oras` varchar2(40), `tip_bucatarie` varchar2(40), `rating` number(2,1), `telefon` varchar2(20)
`Comenzi`	`idc` number(5), `idr` number(3), `data_comanda` date, `valoare` number(7,2), `metoda_plata` varchar2(20), `status` varchar2(20)

Legătura dintre cele două tabele se face prin coloana idr.

Cerințe:

a) Să se șteargă din tabela Comenzi comenzile cu status „ANULATA"; b) Afișați numele restaurantelor și numărul comenzilor anulate.

Rezolvare

SQL

-- ATENTIE la ordine: cerinta b) NUMARA exact randurile pe care cerinta a) le
-- STERGE. Executata dupa a), interogarea b) intoarce zero randuri. Se ruleaza
-- deci b) INTAI, apoi a). Vezi explicatia.

-- b) Restaurantele si numarul lor de comenzi anulate
SELECT r.nume, COUNT(c.idc) AS nr_anulate
FROM Restaurante r
INNER JOIN Comenzi c ON r.idr = c.idr
WHERE c.status = 'ANULATA'
GROUP BY r.nume
ORDER BY nr_anulate DESC;

-- a) Stergerea comenzilor anulate
DELETE FROM Comenzi
WHERE status = 'ANULATA';

Cum funcționează

Enunțul se contrazice — și asta e observația care se punctează

Cerința a) șterge comenzile anulate. Cerința b) cere numărul comenzilor anulate. Executate în ordinea din subiect, a doua întoarce zero rânduri: nu mai există ce să numeri.

Nu e o eroare de citire, e o inconsecvență a subiectului oficial. Sunt trei reacții posibile, dintre care doar una e bună:

Rulezi în ordinea din enunț și b) iese gol. Tehnic „corect", practic un răspuns inutil.
Scrii b) fără să observi că a) i-a tăiat datele — cel mai frecvent, pentru că fiecare cerință pare corectă privită separat.
Inversezi ordinea de execuție și explici de ce — numeri cât încă ai ce număra, apoi ștergi.

A treia variantă e cea scrisă mai sus. Comentariul din cod nu e decorativ: arată corectorului că inversiunea e deliberată.

Aceeași situație apare la orice subiect care combină DELETE cu o statistică pe rândurile șterse. Un DELETE nu se poate anula — datele nu mai există. De aceea, într-o bază reală, ștergerea se înlocuiește cu o coloană anulata (0/1) sau se face o copie înainte:

INSERT INTO Comenzi_anulate SELECT * FROM Comenzi WHERE status = 'ANULATA';
DELETE FROM Comenzi WHERE status = 'ANULATA';

`DELETE` — sintaxa și singura ei capcană

DELETE FROM Comenzi WHERE status = 'ANULATA';

Nu se scrie nicio coloană: DELETE șterge rânduri întregi, nu valori. Dacă voiai să golești doar un câmp, aceea e o operație de UPDATE cu SET câmp = NULL.

Iar WHERE e, ca la UPDATE, singurul lucru care stă între tine și golirea tabelului:

DELETE FROM Comenzi;     -- sterge TOATE comenzile. Fara confirmare, fara mesaj.

b) `COUNT` pe grupuri, după filtrare

Structura e cea de la problema #137: WHERE păstrează doar comenzile anulate, GROUP BY r.nume le așează pe restaurante, COUNT numără în fiecare grup. Restaurantele fără comenzi anulate nu apar — și aici e corect, pentru că se cer restaurantele cu comenzi anulate. (Dacă s-ar cere „toate restaurantele, cu numărul de anulări", ar trebui LEFT JOIN și condiția mutată în ON.)

Greșeli frecvente

Executarea în ordinea din enunț fără să observi conflictul — b) iese gol și crezi că ai greșit interogarea.
DELETE FROM Comenzi fără WHERE — tabelul se golește. Ireversibil.
DELETE valoare FROM Comenzi WHERE ... — DELETE nu ia coloane. Eroare de sintaxă.
WHERE status = 'Anulata' — în Oracle nu potrivește 'ANULATA'; zero rânduri șterse, și pare că instrucțiunea n-a rulat.
COUNT(*) cu LEFT JOIN — restaurantele fără anulări ar apărea cu 1. Vezi problema #128.
GROUP BY uitat — un singur număr total, nu câte unul pe restaurant.

Apariții

Galati 2026 — problema 20 · sursa oficială