#139Baze de date

Baze de date FOOD_DELIVERY — majorarea cu 10% a comenzilor plătite cash

updateselect afisare →filtrarecalcul procentualjonctiuni

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 majoreze cu 10% valoarea comenzilor plătite „cash"; b) Afișați numele restaurantelor și valorile comenzilor plătite „cash".

Rezolvare

SQL

-- a) Majorarea cu 10% a comenzilor platite cash
UPDATE Comenzi
SET valoare = ROUND(valoare * 1.1, 2)
WHERE metoda_plata = 'cash';

-- b) Restaurantele si valorile comenzilor platite cash (dupa majorare)
SELECT r.nume, c.valoare
FROM Restaurante r
INNER JOIN Comenzi c ON r.idr = c.idr
WHERE c.metoda_plata = 'cash'
ORDER BY c.valoare DESC;

Cum funcționează

„Majorare cu 10%” = înmulțire cu 1.1

Trei scrieri dau același rezultat; important e să înțelegi de ce:

Scris	Ce înseamnă
`valoare * 1.1`	valoarea + 10% din ea, într-o singură operație
`valoare + valoare * 0.1`	explicit: valoarea plus 10% din ea
`valoare + valoare * 10 / 100`	la fel, cu procentul scris ca fracție

Și una care nu e corectă, deși pare:

SET valoare = valoare * 10 / 100      -- GREȘIT: da 10% DIN valoare, adica o scade cu 90%

Diferența dintre „majorează cu 10%" și „calculează 10% din" e toată problema. O comandă de 100 devine 110 în primul caz și 10 în al doilea. Rezultatul rămâne un număr credibil, deci greșeala nu se vede decât dacă compari cu datele de dinainte.

Capcana împărțirii întregi, dacă coloana ar fi întreagă: în Oracle și în multe sisteme, valoare * 10 / 100 cu valori întregi poate trunchia la fiecare pas. Ordinea contează — înmulțește întâi, împarte după — iar cel mai sigur e factorul zecimal (* 1.1).

ROUND(..., 2) păstrează două zecimale, în ton cu number(7,2) din structura tabelului. Fără el, 145.50 * 1.1 ar putea ajunge 160.05000000000001, stocat ca atare.

`WHERE` obligatoriu aici

Spre deosebire de problema #125, unde enunțul cerea explicit „fiecărui angajat", aici se majorează doar comenzile plătite cash. Fără WHERE, toate cele 14 comenzi cresc cu 10% — și nu există niciun mesaj de eroare, doar date greșite pentru totdeauna.

Ordinea cerințelor schimbă rezultatul afișat

Cerința b) afișează valorile de după majorare, dacă rulezi a) prima. Așa e și ordinea din enunț, deci așa e corect. Dacă ai rula b) înainte de a), aceleași interogări ar da alte numere — motiv suficient să respecți ordinea din subiect.

O problemă unde ordinea contează și mai brutal (a) șterge exact ce numără b)) e #140.

Greșeli frecvente

SET valoare = valoare * 10 / 100 — scade valoarea la 10% din ea. Rezultat plauzibil, complet greșit.
SET valoare = 1.1 — înlocuiește valoarea cu 1.1. Datele originale sunt pierdute.
WHERE uitat — se majorează toate comenzile, inclusiv cele cu cardul.
'Cash' cu majusculă — în Oracle nu potrivește 'cash'; UPDATE afectează zero rânduri și pare că „nu a funcționat".
UPDATE fără rotunjire — apar valori cu 15 zecimale în coloana de bani.
SET valoare = valoare + 10 — adaugă 10 lei, nu 10 procente. Diferența se vede doar la comenzile mari.

Apariții

Galati 2026 — problema 19 · sursa oficială