[SQL] Un parere su una query: annidamento <vs> HAVING.

[Matrixbob]

Qual’è + standard?
L’having non dovrebbe essere venuto dopo per semplificare la vita con le funzioni aggregate, mentre gli annidamenti di SELECT erano già standard?
Vantaggi e svantaggi dei 2 approci? Sono equivalenti?
TNX.

http://img691.imageshack.us/img691/4946/selectcore.gif

QUERY1]

SELECT tmp.nome, COUNT( * )
FROM (
SELECT ospedale.nome, ospedale.id
FROM ospedale
INNER JOIN reparto ON ospedale.id = reparto.ospedale
INNER JOIN personale ON reparto.id = personale.reparto
WHERE personale.cognome = 'Crastelli'
) AS tmp, reparto
WHERE tmp.id = reparto.ospedale


QUERY2]

SELECT ospedale.nome AS "ospedale" , COUNT(*) AS "numero reparti"
FROM reparto
JOIN ospedale ON reparto.ospedale = ospedale.id
GROUP BY reparto.ospedale
HAVING reparto.ospedale IN
(SELECT ospedale.id
FROM ospedale
JOIN reparto ON reparto.ospedale = ospedale.id
JOIN personale ON personale.reparto = reparto.id
WHERE personale.cognome = "Crastelli");

[gugoXX]

A parte che l'esempio non e' ottimale in quanto la HAVING si usa sulle funzioni di gruppo (Count, Sum, Avg, etc.) e non sugli attributi di Group BY (per i quali e' invece sempre preferibile una WHERE a priori, prima di eseguire i raggruppamenti)
la risposta e' si'.
Una Having puo' essere sempre trasformata in una WHERE su una SELECT annidata.


SELECT abc, Count(*) as CNT
FROM tabella
GROUP BY abc
HAVING Count(*)>12

SELECT * FROM (
SELECT abc, Count(*) as CNT
FROM Tabella
Group by abc
) Where CNT>12

Con gli stessi identici piani di esecuzione.

Quello che si perde senza having e' una maggiore leggibilita' e un formalismo particolare che puo' aiutare certi tool di reportistica o business intelligence.
Ma per il resto se ne potrebbe fare a meno, tantopiu' che si trova spesso usata laddove non si sarebbe dovuto usare e rischierebbe di fare piu' danni che benefici (come, non me ne volere, nel tuo esempio)

[Matrixbob]

A parte che l'esempio non e' ottimale in quanto la HAVING si usa sulle funzioni di gruppo (Count, Sum, Avg, etc.) e non sugli attributi di Group BY (per i quali e' invece sempre preferibile una WHERE a priori, prima di eseguire i raggruppamenti)
la risposta e' si'.
Una Having puo' essere sempre trasformata in una WHERE su una SELECT annidata.


SELECT abc, Count(*) as CNT
FROM tabella
GROUP BY abc
HAVING Count(*)>12

SELECT * FROM (
SELECT abc, Count(*) as CNT
FROM Tabella
Group by abc
) Where CNT>12

Con gli stessi identici piani di esecuzione.

Quello che si perde senza having e' una maggiore leggibilita' e un formalismo particolare che puo' aiutare certi tool di reportistica o business intelligence.
Ma per il resto se ne potrebbe fare a meno, tantopiu' che si trova spesso usata laddove non si sarebbe dovuto usare e rischierebbe di fare piu' danni che benefici (come, non me ne volere, nel tuo esempio)

Quindi la query2 la vedi meno corretta, giusto?

[gugoXX]

Quindi la query2 la vedi meno corretta, giusto?

Si', perche' usa la HAVING in modo sbagliato e fa 2 JOIN quasi identiche, le seconde delle quali potrebbero essere evitate.

[DaNi89]

ragazzi ne approfitto della discussione già aperta per chiedere una cosa, nella progettazione di un database a un certo punto arrivato allo schema relazionale mi sono accorto che una chiave esterna può essere associata a più attributi di diverse entità, ecco l'esempio:
Torneo (id, giornoInizio, giornoFine, orarioInizio, orarioFine, numGiocatori, numPartite, vincitore)
Dirigente (matricola, nome, cognome, indirizzo, telefono, ruolo)
Dipendente (matricola, nome, cognome, indirizzo, telefono, ruolo)
Socio (matricola, codFiscale, nome, cognome, indirizzo, telefono, ruolo, allenamento, numVittorie)
GiocatoreEsterno (num, codFiscale, allenamento, numVittorie)
Come vedete a vincere il torneo può essere un dirigente, un dipendente o un socio con la loro matricola, oppure un giocatore esterno con il suo numero identificativo progressivo.
Quando vado a dichiarare le chiavi esterne, l'attributo vincitore lo posso collegare a tutti e 4 questi attributi o non si può fare?
ALTER TABLE TORNEO
ADD FOREIGN KEY (VINCITORE) REFERENCES SOCIO(MATRICOLA),
ADD FOREIGN KEY (VINCITORE) REFERENCES DIRIGENTE(MATRICOLA),
ADD FOREIGN KEY (VINCITORE) REFERENCES DIPENDENTE(MATRICOLA),
ADD FOREIGN KEY (VINCITORE) REFERENCES GIOCATORE_ESTERNO(NUM);
questo si può fare?
grazie per le risposte

[gugoXX]

No, non si puo' fare.
Si puo' pero' fare subclassing.
Puoi creare una tabella Padre di tutte e 4 quelle entita', chiamata semplicemente
GIOCATORE, con tutti gli attributi comuni, come
Matricola (Sempre chiave primaria)
Nome, Cognome, Inidirzzo, Telefono, Ruolo.
Ovviamente togliendo le colonne relative dalla tabella specifica.
Ognuna delle altre 4 entita' tabella puntera' in chiave straniera a questa tabella padre (ovvero, se esiste un socio, tale socio deve essere anche anagrafato nella tabella giocatore)
E la tua tabella associativa finale relativa al torneo puntera' a questa sola tabella Giocatore.

[DaNi89]

perfetto immaginavo che si dovesse fare così, grazie mille