[SQL] ALL en ANY

[Suffie]

is er een manier om de ALL en ANY operator te omzeilen (door een andere operator?), want ik snap ze helemaal niet.

bijvoorbeeld:
geef de naam en geboortedatum van de oudste spelers ->

code:

SELECT naam, geb_datum FROM spelers 
WHERE geb_datum <= ALL 
(SELECT geb_datum FROM spelers)

vervangen door zoiets als

code:

SELECT naam, geb_datum FROM spelers WHERE geb_datum = "maximum"

en dan voor maximum een andere expressie natuurlijk

[whoami]

Met welk DBMS werk jij want die operators ken ik echt niet ....
Je eerste query kan je toch herschrijven als:

code:

select naam, geb_datum
FROM spelers
where geb_datum <= (select max(geb_datum) from spelers)

[Verwijderd]

SELECT TOP 10 naam, geb_datum FROM spelers ORDER BY geb_datum;

[Suffie]

whoami schreef op 04 november 2002 @ 15:50:
Met welk DBMS werk jij want die operators ken ik echt niet ....
Je eerste query kan je toch herschrijven als:

code:

select naam, geb_datum
FROM spelers
where geb_datum <= (select max(geb_datum) from spelers)

met Solid Server, Interbase schijnt ze ook te hebben want dat wordt dit jaar gebruikt op school

dank je voor de statement, en als je max door min vervangt werkt het idd

maar of dit voor alle ALL en ANY dingen geldt weet ik nog neit

[LegacyCode]

ALL en ANY gebruik je als je subquery meerdere rijen retourneert.
Zo is het toch in oracle.

[Verwijderd]

ALL en ANY worden ook door MS SQL ondersteunt.

uit de help:
SELECT t1.type
FROM titles t1
GROUP BY t1.type
HAVING MAX(t1.advance) >= ALL
(SELECT 2 * AVG(t2.advance)
FROM titles t2
WHERE t1.type = t2.type)

[Suffie]

deze werkt overigens ook:
SELECT naam FROM spelers WHERE geb_datum = (SELECT MIN(geb_datum) FROM spelers);

[whoami]

Suffie schreef op 04 november 2002 @ 16:06:
deze werkt overigens ook:
SELECT naam FROM spelers WHERE geb_datum = (SELECT MIN(geb_datum) FROM spelers);

Ja, maar wel met een subtiel verschil. Met deze query krijg je enkel de spelers die de kleinste geboortedatum hebben.

[Suffie]

whoami schreef op 04 november 2002 @ 16:07:

[...]


Ja, maar wel met een subtiel verschil. Met deze query krijg je enkel de spelers die de kleinste geboortedatum hebben.

wat is het verschil dan?

[Verwijderd]

Verwijderd schreef op 04 november 2002 @ 15:53:
SELECT TOP 1 naam, geb_datum FROM spelers ORDER BY geb_datum;

Dit is de enige goede oplossing. De rest voert allemaal twee SELECTs uit en is dus twee keer zo lang bezig.

[whoami]

Denk zelf eens na: wat is het verschil tussen = en < , >, <= , >=
als je doet:

code:

select * from .... where datum <= ( select max(....))

Dan krijg je alle spelers waarvan de geboortedatum kleiner is of gelijk is aan de grootste geboortedatum. Je krijgt dan dus eigenlijk alle spelers.
Doe je = ipv <= dan krijg je enkel de speler met de grootste geboortedatum.

[whoami]

Verwijderd schreef op 04 november 2002 @ 16:09:
[...]

Dit is de enige goede oplossing. De rest voert allemaal twee SELECTs uit en is dus twee keer zo lang bezig.

Niet echt. Het is niet omdat er 2 selects zijn dat het daarvoor 2x zolang duurt.
(En het is niet omdat de ene oplossing langer duurt, dat ze daarvoor niet goed is).
(Die ORDER BY kan trouwens ook nogal een vertragende werking hebben).

Trouwens, die oplossing doet imo heel wat anders dan de andere oplossingen.

[Suffie]

de "opdracht" was:
geef de naam en geboortedatum van de oudste spelers

dus ik wilde ook alleen de speler die het oudste was?
dan is t toch goed?

[whoami]

Suffie schreef op 04 november 2002 @ 16:19:
de "opdracht" was:
geef de naam en geboortedatum van de oudste spelers

dus ik wilde ook alleen de speler die het oudste was?
dan is t toch goed?

Dan moet je idd enkel die = gebruiken, en is de <= fout. (Maar die had je wel gebruikt in je openingspost )

[Verwijderd]

whoami schreef op 04 november 2002 @ 16:12:

[...]


Niet echt. Het is niet omdat er 2 selects zijn dat het daarvoor 2x zolang duurt.
(En het is niet omdat de ene oplossing langer duurt, dat ze daarvoor niet goed is).
(Die ORDER BY kan trouwens ook nogal een vertragende werking hebben).

Trouwens, die oplossing doet imo heel wat anders dan de andere oplossingen.

ORDER BY kan inderdaad een vertraagde werking hebben, maar ten eerste denk ik niet dat je zoveel personen in een tabel krijgt waardoor dit een probleem gaat opleveren. En tweedens kan je dan simpel een index op dit veld leggen als je met een goed DBMS werkt...

Andere oplossingen raad ik niet aan.

[whoami]

Verwijderd schreef op 04 november 2002 @ 16:38:
[...]


ORDER BY kan inderdaad een vertraagde werking hebben, maar ten eerste denk ik niet dat je zoveel personen in een tabel krijgt waardoor dit een probleem gaat opleveren. En tweedens kan je dan simpel een index op dit veld leggen als je met een goed DBMS werkt...

Andere oplossingen raad ik niet aan.

Jouw oplossing zou enkel het juiste resultaat leveren als je het zo schrijft:

code:

SELECT TOP 1 speler FROM spelers ORDER BY geb_datum DESC

En dan kan het nog goed zijn dat het dbms een sequential table scan gaat gaan uitvoeren.

Sommige DBMS'en gebruiken geen indexen bij het sorteren, en ik denk wel dat je makkelijk zodanig veel records in een tabel kunt krijgen dat dat wel degelijk uitmaakt. Trouwens, die indexen worden ook wel gebruikt bij die subqueries.

[Verwijderd]

Jouw oplossing zou enkel het juiste resultaat leveren als je het zo schrijft:

code:

SELECT TOP 1 speler FROM spelers ORDER BY geb_datum DESC

Niet mee eens! Hiermee krijg je de meest recente datum bovenaan, dus daarmee is de leeftijd van die persoon het kleinst (dus de jongste persoon). En je wilde juist de oudste hebben... dacht ik...

[whoami]

Verwijderd schreef op 04 november 2002 @ 17:04:
Jouw oplossing zou enkel het juiste resultaat leveren als je het zo schrijft:

code:

SELECT TOP 1 speler FROM spelers ORDER BY geb_datum DESC

Niet mee eens! Hiermee krijg je de meest recente datum bovenaan, dus daarmee is de leeftijd van die persoon het kleinst (dus de jongste persoon). En je wilde juist de oudste hebben... dacht ik...

Euhm, ja... foutje. Maandag he... . Dan doe je gewoon:

code:

ORDER BY geb_datum ASC

_Miereneuker

[Verwijderd]

_Miereneuker

Verbeter me dan niet foutief...

[Verwijderd]

whoami schreef op 04 november 2002 @ 16:12:

Niet echt. Het is niet omdat er 2 selects zijn dat het daarvoor 2x zolang duurt.
(En het is niet omdat de ene oplossing langer duurt, dat ze daarvoor niet goed is).
(Die ORDER BY kan trouwens ook nogal een vertragende werking hebben).

Trouwens, die oplossing doet imo heel wat anders dan de andere oplossingen.

Ik had dat natuurlijk wel even getest, MS Query Analyzer even een Execution Plan laten fabriceren. Al die WHERE oplossingen kosten 2x zoveel als de ORDER BY oplossing.
Als je twee SELECTs hebt dan wordt de Index/Table scan gewoon 2x uitgevoerd. En dan nog wat overhead om die resultaten te vergelijken en te combineren.

[cameodski]

Verwijderd schreef op 04 november 2002 @ 18:26:
Ik had dat natuurlijk wel even getest, MS Query Analyzer even een Execution Plan laten fabriceren. Al die WHERE oplossingen kosten 2x zoveel als de ORDER BY oplossing.
Als je twee SELECTs hebt dan wordt de Index/Table scan gewoon 2x uitgevoerd. En dan nog wat overhead om die resultaten te vergelijken en te combineren.

De performance van een query hangt niet af van het aantal select statements wat er in de query staat, maar veel meer van de complexiteit van de verschillende statements.
Het is een kleine moeite om een simpel select statement te verzinnen die zo traag is dat er nooit van z'n leven meer wat uit komt.
Maar in de praktijk zal inderdaad de variant zonder de subquery het meest efficient zijn.