[MySQL] Where not exists werkt niet

[Verwijderd]

code:

SELECT leden.login 
FROM leden 
WHERE NOT EXISTS 
(SELECT * 
FROM aanmelden 
WHERE leden.login = aanmelden.login)

Ik wil alle loginnamen selecteren die zich niet hebben aan- of afgemeld (die geen reactie hebben gegeven dus). Op deze manier werkt het echter niet, ik krijg hierbij de volgende foutmelding:

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/virtual/site21/fst/var/www/html/detailsaanmelden.php on line 51

[P_de_B]

code:

SELECT leden.login
FROM leden
LEFT OUTER JOIN aanmelden ON leden.login = aanmelden.login
WHERE aanmelden.login IS NULL

Bovenstaande is iets eenvoudiger en werkt ook in oudere MySQL versies. Dit selecteert alle leden die niet in de aanmelden tabel voorkomen.

[Verwijderd]

Hartelijk dank, probleem opgelost!

[Swa-baldie]

code:

SELECT lid.login 
FROM    leden         lid
,    aanmelden amd
WHERE lid.login = amd.login(+)
and        amd.login is null

werkt ook

verder zou ik de * niet gebruiken in de constructie die je gebruikt maar gewoon een dummy kolom (scheelt al weer systeemload)

[ Voor 1% gewijzigd door Swa-baldie op 02-03-2005 16:44 . Reden: copy paste foutje in de from clause ]

[curry684]

Swa-baldie schreef op woensdag 02 maart 2005 @ 16:30:

code:

SELECT lid.login 
FROM    leden         lid
FROM    aanmelden amd
WHERE lid.login = amd.login(+)
and        amd.login is null

werkt ook

Wat is dat voor brakke syntax? Mag je in MySQL serieus 2 FROM-clauses meegeven?

verder zou ik de * niet gebruiken in de constructie die je gebruikt maar gewoon een dummy kolom (scheelt al weer systeemload)

Een goede query optimizer geeft het na 1 row op als de subquery enkel in een EXISTS gebruikt wordt.

[P_de_B]

Swa-baldie schreef op woensdag 02 maart 2005 @ 16:30:


verder zou ik de * niet gebruiken in de constructie die je gebruikt maar gewoon een dummy kolom (scheelt al weer systeemload)

Juist EXISTS queries zijn de uitzondering die de regel bevestigd. Wanneer je * gebruikt kan de query enigine zelf kiezen welke index (indien van toepassing) hij kan gebruiken

[Swa-baldie]

P_de_B schreef op woensdag 02 maart 2005 @ 16:38:
[...]

Juist EXISTS queries zijn de uitzondering die de regel bevestigd. Wanneer je * gebruikt kan de query enigine zelf kiezen welke index (indien van toepassing) hij kan gebruiken

je wil juist dat de engine gebruikt maakt van de index op de join en niet op de '*'. verder heeft de '*' hier verder ook geen enkele nuttige toevoeging, Je selecteer eigenlijk niks in de subquery. dus een dummy kolom zegt dan meer. (Zie trouwens net dat het over mysql gaat, mijn opmerkingen gaan in ieder geval op voor een Oracle db, mysql durf ik niet te zeggen)

[ Voor 14% gewijzigd door Swa-baldie op 02-03-2005 16:46 ]

[P_de_B]

Swa-baldie schreef op woensdag 02 maart 2005 @ 16:43:
[...]


je wil juist dat de engine gebruikt maakt van de index op de join en niet op de '*'. verder heeft de '*' hier verder ook geen enkele nuttige toevoeging, Je selecteer eigenlijk niks in de subquery. dus een dummy kolom zegt dan meer.

Nee, want de EXISTS is in dit geval een subquery waarbij je wilt dat de optimizer zelf een index kiest omdat 'ie daar nu eenmaal voor geleerd heeft

[Verwijderd]

Nu komt er alleen een volgend probleem... Met de bovenstaande code wordt iedereen die nog geen reactie heeft gegeven, geselecteerd. Bij vergadering nr. 2 moet echter iedereen weer bij "geen reactie" komen. Iedere vergadering heeft een aparte id, deze zal ergens in moeten worden geplaatst.

code:

SELECT achternaam, voorletters, tussenvoegsel 
FROM leden 
LEFT OUTER JOIN aanmelden ON leden.login = aanmelden.login 
WHERE aanmelden.id <> $id 
AND aanmelden.login IS NULL

De id van de huidige vergadering is opgeslagen in een variabele. Volgens mij is de plaats in de bovenstaande regel niet helemaal correct...

[Verwijderd]

Is al opgelost, was vergeten om erbij te vermelden dat de login dan niet null moest zijn

[Swa-baldie]

P_de_B schreef op woensdag 02 maart 2005 @ 16:46:
[...]


Nee, want de EXISTS is in dit geval een subquery waarbij je wilt dat de optimizer zelf een index kiest omdat 'ie daar nu eenmaal voor geleerd heeft

Ik zei ook voor de optimizer van Oracle weet ik het zeker (kijk maar op metalink.oracle.com of asktom.oracle.com icm exists). Wordt een beetje welles nietes zo.

[P_de_B]

Swa-baldie schreef op donderdag 03 maart 2005 @ 07:23:
[...]


Ik zei ook voor de optimizer van Oracle weet ik het zeker (kijk maar op metalink.oracle.com of asktom.oracle.com icm exists). Wordt een beetje welles nietes zo.

Nou, dan zal Oracle het wel anders doen dan bijvoorbeeld MS SQL Server, laten we het daar maar op houden.