Newsgroup: it.comp.software.database
Titolo: Dubbio su SQL

Un saluto a tutto il newsgroup,
	volevo chiedere se esiste nello standard qualcosa che determina
l'ordine di interpretazione delle clausole di una interrogazione. Ve
lo chiedo perche' le mie ricerche sono andate a vuoto, e anche perche'
la mia docente ha le idee un po' confuse a riguardo. Esempio :
SELECT Stipendio*1000
FROM Impiegati
WHERE Stipendio > 1.000.000;
Ora e' evidente che il risultato della query combia a seconda che sia
la SELECT ad essere interpretata prima della WHERE. Logicamente
dovrebbe essere fatta prima la WHERE, ma lo standard cosa dice? Mi
rendo conto che l'esempio e' banale, ma quando entrano in gioco GROUP
BY, HEAVING e soci in una query complessa, le cose non sono piu' molto
evidenti. Allora la domanda :
Esiste da standard un ordine di interpretazione delle clausole di una
interrogazione? (Ex prima la select, poi la where ecc..).
Grazie mille a chi mi rispondera'
[}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{]
SunGray aka Gabriele Lana  
www.redangel.it
www.sungray.com
contact me @ : 
www.redangel.it
contact me @ : 
sun...@tiscalinet.it
[}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{]

 Grazie mille a chi mi rispondera'
Dalla mia esperienza posso dirti che non e' chiaro cosa venga eseguito 
prima, ma sicuramente l'espressione sull'attributo Stipendio e' calcolata 
per ultima.
Tenendo in mente cio', che vengano prima selezionati i campi, o che venga 
prima applicata la where alle riche, e' la stessa cosa.
Nel tuo caso vengono comunque selezionate le righe per cui lo stipendio e' 
maggiore di 1M, delle quali viene preso solo l'attributo stipendio e POI 
moltiplicato per 1000.
Per GROUP BY ed HAVING puoi pensare che avvenga cio':
-prima la where (selezione delle righe)
-group by (raggruppa le righe in insemi omogenei) e gli operatori aggregati 
applicati a questi insiemi (sum, avg, max, min...)
-having, che seleziona solo alcuni insiemi in base a certe condizioni (puoi 
vedere la cosa come un where che lavora sui gruppi di righe omogenee 
piutosto che sulle singole righe).
Come il DBMS faccia cio' e' dipendente dall'impklementazione 
dell'ootimizzatore e dell'esecutore delle query.
-- 
frank@office
P|||@450MHz-320MB-DebWoody/Sid

L'ordine dovrebbe essere:
- Prende le tabelle indicate nella FROM (claro...)
- Esegue il prodotto cartesiano delle tabelle
- Applica le condizioni della clausola WHERE
- Raggruppa l'insieme finale secondo le indicazioni della GROUP BY
- Restringe eventualmente il result set secondo le condizioni della HAVING
- Esegue la proiezione indicata nella SELECT (con l'eventuale DISTINCT) e
l'eventuale ORDER BY
Credo che ciò sia comunque indipendente dal DBMS utilizzato e dal relativo
ottimizzatore delle query, cioè l'ordine 'logico' è questo, il piano
d'accesso scelto poi dall'ottimizzatore è un altro discorso...
Bye                     Claudio lo squilibrio
"Frank" <NOf....@libero.itSPAM> ha scritto nel messaggio
news:9r3hkv$9nk$1...@uno.vitaminic.net...


 
Nello spazio di pensiero chiamato : it.comp.software.database 
Ha scritto questo messaggio : 
Grazie ad entrambi ragazzi, mi sono informato anche io sullo standard
e anche grazie ai vostri suggerimenti potrei concludere che :
le clausole di una interrogazione vengono interpretate in questo
ordine
- FROM
- WHERE
- GROUP BY
- HEAVING
- Funzioni di gruppo nella clausola SELECT
- SELECT
[}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{]
SunGray aka Gabriele Lana  
www.sungray.com


 - HEAVING
HAVING....(dal verbo to have, avere...)
-- 
frank@office
P|||@450MHz-320MB-DebWoody/Sid

ma lo standard cosa dice?
La tua query non cambia il valore del campo, quindi non c'e'
ambiguita'. Detto questo anche se lo cambiasse c'e' rischio di
ricorsioni o comportamenti "folli" se le clausole di filtro agissero
dopo la selezione (cosa folle anche dal punto di vista logico n.d.p.)
L'esempio corretto e':
UPDATE Tabella
SET campo_con_segno = -1 * campo_con_segno
WHERE campo_con_segno > 0
-- 
Tieni per te il Papero giusto se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

 l'eventuale ORDER BY
dipende da cosa c'e' nella clausola where, se sono coinvolti degli indici,
viene fatta una proiezione, vista, delle tabelle coinvolte, in base alle
colonne coinvolte nella clausola where, indici primary key ecc..
dopo viene fatto il prodotto, altrimenti si andrebbe sempre in full scan !?
sostanzialmente:
data una query, viene parsificata dal basso verso l'alto ,
senza considerare le funzioni in essa presenti.


Sě, č vero, ma io nel precedente messaggio ho specificato che questo č
l'ordine 'logico', l'ordine con cui esaminare la query, e non il piano
d'accesso fisico a disco scelto dall'ottimizzatore...
Sorry, forse mi sono espresso male...
Bye...

 wrote in message
news:9r681s$471$1...@pluto.news.dsi.unimi.it...

non sia mai !