Newsgroup: it.comp.software.database
Titolo: Tipo di sintassi delle query

Ho tre tabelle con un campo comune che e' anche la chiave delle
singole tabelle,
non ci sono altri indici sulle tabelle.
Ha un qualche vantaggio scrivere la query come
SELECT nomeCampi
FROM Tab_1 JOIN Tab_2
ON Tab_1.key = Tab_2.key
JOIN Tab_3
ON Tab_2.key = Tab_3.key
WHERE
Tab_3.key = 'keyVal';
Invece che con il "piu' classico"
SELECT nomeCampi
FROM Tab_1, Tab_2, Tab_3 WHERE
Tab_1.key = Tab_2.key AND
Tab_2.key = Tab_3.key AND
Tab_3.key = 'keyVal';
A parte il mio caso specifico, esistono casi in cui si hanno vantaggi
a scrivere query con la sintassi del primo tipo?
Grazie in anticipo.
C:\>iao Angelo

 a scrivere query con la sintassi del primo tipo?
In caso di *inner* Join non ci sono differenze logiche (stessi record
restituiti), e se non erro molti DBMS le risolvono nello stesso modo (ma
potrei sbagliarmi, e sicuramente non sarà così nel 100% dei casi).
La Join AFAIK non è *mai* più lenta, quindi io uso sempre la join, in
questi casi. Inoltre in casi particolari può risultare più flessibile.
Inoltre la trovo sempre più chiara.

 a scrivere query con la sintassi del primo tipo?
In caso di *inner* Join non ci sono differenze logiche (stessi record
restituiti), e se non erro molti DBMS le risolvono nello stesso modo (ma
potrei sbagliarmi, e sicuramente non sarà così nel 100% dei casi).
La Join AFAIK non è *mai* più lenta, quindi io uso sempre la join, in
questi casi. Inoltre in casi particolari può risultare più flessibile.
Infine la trovo sempre più chiara a livello di rilettura.

 Infine la trovo sempre più chiara a livello di rilettura.
E l'esempio specifico è ancora più semplice con NATURAL JOIN o sbaglio?

 vantaggi a scrivere query con la sintassi del primo tipo?
Assai difficile, forse solo in dbms molto limitati.
Una volta non c'era il cost based optimizer, ma solo la
generazione di un piano di esecuzione basato su delle "regolette",
norme di massima che funzionavano nei casi piu' comuni.
In questi casi, il modo in cui si scriveva la query,
effettivamente poteva fare una qualche differenza. [*]
In termini di prestazioni, l'ottimizzazione sintattica (si chiama
cosi' questo tipo di trasformazione) e` sempre meno utile
col passare del tempo, a causa di optimizer sempre piu`
sofisticati.
Tieni conto che la query passa gia` una fase di query rewrite,
in cui la riscrittura in forma piu` favorevole viene fatta dal
dbms, generando una rosa di query semanticamente equivalenti.
Dopodiche' query optimizer "pesa" ciascuna di queste query
valorizzandola con un costo, generando un query plan che
tiene anche conto di cose non espresse nella query (indici,
vincoli, carico del server al momento attuale).
Il bello non e` solo che arrivati a questo punto la query
e` gia` stata rivoltata come un calzino piu` volte, ma anche
che query differenti possono dare piani di esecuzione uguali,
rendendo l'ottimizzazione manuale raramente utile.
Dal punto di vista "estetico" invece, la forma in ANSI SQL
ha una miglior divisione tra l'espressione di JOIN e quella
in WHERE, evitando, nei casi di join multitabella, di
affollare la clausola WHERE; rende cristallino su cosa il
dbms deve joinare e su cosa deve filtrare.
bye
[*] Nei dbms rudimentali si assegna un punteggio alle varie
operazioni, ad es. come segue:
WHERE Prezzo = 123
confronto con costante: 8 punti
colonna gia` in formato numerico: 5 punti
operatore di uguaglianza: 10 punti
Totale: 23 punti
Poi la si confronta con un'altra formulazione della query.
Quella che ha il punteggio piu' alto viene mandata in
esecuzione. 

 E l'esempio specifico è ancora più semplice con NATURAL JOIN o sbaglio?
Firebird NATURAL JOIN non sa che è, quindi non so se tutti la riconoscono.