[SQL] query te zwaar

[maartenvdv737]

Kan iemand mij vertellen waarom deze query mijn hele server laat flippen sinds ik het IF-gedeelte heb toegevoegd?

In achting nemend dat:
er maar 1 row is in reacties2
2 rows in avatar
2 rows in gebruikers2


Ik snap dat ik hier een extra proces toevoeg, maar zo zwaar lijkt die me nou ook weer niet.

code:

SELECT
    reacties2.id as reactieID,
    IF(avatars.avatar IS NULL, NULL, CONCAT(
                       '<img src=\"',avatars.avatar,'\" width=60 height=60 
                       border=0'>)) as avatar,
    gebruikers2.gebruikersnaam,
    gebruikers2.email,
    DATE_FORMAT(reacties2.datum, '%d-%m-%Y %H:%i') as tijd,
    bericht
FROM
    reacties2
 LEFT JOIN
    gebruikers2
ON
    gebruikers2.id = reacties2.gebruikersID
 LEFT JOIN
    avatars
ON
    avatars.gebruikersID = gebruikers2.id
WHERE
    reacties2.spelID = $id
ORDER BY
    reacties2.id DESC
 LIMIT   
    $start,$max

[whoami]

Een IF in een SELECT.... Da's ook de eerste keer dat ik dat zie.

[maartenvdv737]

ja, je hebt het ook zelden nodig, maar ik heb het wel nodig nu.

[André]

Op die plek in een select geef je toch gewoon de kolommen aan, waarom moet daar dan een if-statement staan? Kun je daar niet gewoon "avatars.avatar as avatar" van maken?

[whoami]

Ik snap eigenlijk ook niet echt het nut van die IF hoor....

[Vae Victis]

IF(avatars.avatar IS NULL, NULL, CONCAT(
'<img src=\"',avatars.avatar,'\" width=60 height=60
border=0'>)) as avatar,

Volgens mij staat er iig een ' verkeerd
Moet dacht ik zijn ->

code:

IF(avatars.avatar IS NULL, NULL, CONCAT(
                       '<img src=\"',avatars.avatar,'\" width=60 height=60 
                       border=0>')) as avatar,

Over discussie of die 'if' daar lekker staat hou ik me buiten

[eborn]

whoami schreef op 01 July 2003 @ 20:32:
Ik snap eigenlijk ook niet echt het nut van die IF hoor....

De IF zorgt ervoor dat je, zodra er een avatar is, een correcte IMG tag terugkrijgt met de avatar. Als er geen avatar is krijg je gewoon NULL terug. Meestal doe je zoiets in een scriptingtaal, maar het kan natuurlijk ook prima in SQL.

[MBV]

Ben het met André eens. Ik snapte eerst de bedoeling helemaal niet, maar ik vermoed dat het is om geen img-tag als output te geven. Nu is mijn vraag: waarom wil je met SQL HTML-code uit laten poepen? Hebben ze daarvoor niet PHP etc uitgevonden?

PHP:

if ($result['avatar']!= NULL) echo "<img=....>"

Ik weet niet wat voor server je hebt, met wat voor OS, wat voor DBMS etc. info aub?

[ Voor 6% gewijzigd door MBV op 01-07-2003 20:40 ]

[whoami]

eborn schreef op 01 juli 2003 @ 20:39:
[...]
De IF zorgt ervoor dat je, zodra er een avatar is, een correcte IMG tag terugkrijgt met de avatar. Als er geen avatar is krijg je gewoon NULL terug. Meestal doe je zoiets in een scriptingtaal, maar het kan natuurlijk ook prima in SQL.

SQL is niet gemaakt voor zo'n dingen. SQL is er om data te manipuleren , op te halen etc.... Niet om de presentatie van de gegevens al te gaan verzorgen.

[André]

whoami schreef op 01 juli 2003 @ 20:41:
[...]


SQL is niet gemaakt voor zo'n dingen. SQL is er om data te manipuleren , op te halen etc.... Niet om de presentatie van de gegevens al te gaan verzorgen.

* André is het daar mee eens...

Met SQL gewoon gegevens opvragen, opslaan of verwijderen. Andere activiteiten doe je in je script. Ik denk ook dat die if statement je bottleneck is omdat SQL daar idd niet voor bedoeld is.

[ Voor 16% gewijzigd door André op 01-07-2003 20:50 ]

[ACM]

Is de query ook traag als je de if niet hebt, maar wel de avatars.avatar erin toont??
Lijkt me erg vreemd als dat zo is.

@Andre: Die if is extreem snel uit te voeren, dus dat zal en kan de bottleneck haast wel niet zijn. Sterker nog, het is sneller om die if in je query te doen dan achteraf in php, zo is mijn ervaring.

[ Voor 49% gewijzigd door ACM op 01-07-2003 21:13 ]

[oh,when?]

whoami schreef op 01 juli 2003 @ 20:41:
[...]

SQL is niet gemaakt voor zo'n dingen. SQL is er om data te manipuleren , op te halen etc.... Niet om de presentatie van de gegevens al te gaan verzorgen.

Met zo'n bewering zijn bewerkingen zoals date formateringen, string-bewerkingen en wiskundige berekeningen ook niet juist gebruik van SQL. Die verzorgen in principe ook al een deel van een presentatie van je data.

[whoami]

oh,when? schreef op 01 juli 2003 @ 21:14:
[...]

Met zo'n bewering zijn bewerkingen zoals date formateringen, string-bewerkingen en wiskundige berekeningen ook niet juist gebruik van SQL. Die verzorgen in principe ook al een deel van een presentatie van je data.

Hmmm...... In de grond misschien wel, maar eigenlijk ook weer niet.

Date formatteringen doe ik eerlijk gezegd ook niet in SQL.
Wiskundige berekeningen (SUM , AVG, etc....) horen dan weer wel thuis in SQL vind ik. Dat heeft niets met formatting van data te maken, maar met het ophalen van data:
Geef mij het totale omzetcijfer van het eerste kwartaal bv, heeft niets met opmaak te maken.

[Annie]

quote: http://www.mysql.com/doc/en/String_functions.html

CONCAT(str1,str2,...)
Returns the string that results from concatenating the arguments. Returns NULL if any argument is NULL. May have more than 2 arguments. A numeric argument is converted to the equivalent string form:

Het nut van de IF is me dus niet helemaal duidelijk.

offtopic:
Gebruik van string bewerkingen of IF/CASE in een select worden wel vaker gebruikt en zijn imho ook absoluut niet zo verkeerd (zeker omdat je niet altijd inspraak hebt in het datamodel en/of de applicatie die gebruik gaat maken van je data). Alhoewel er vaak ook nog wel andere methoden zijn te bedenken (creatief omgaan met IFNULL- of COALESCE-achtige functies doet ook vaak wonderen als het om nullable velden gaat).

[ Voor 40% gewijzigd door Annie op 01-07-2003 22:35 ]

[zeroxcool]

Waarom die IF. Een NOT ISNULL() volstaat hier prima:

code:

SELECT
    reacties2.id as reactieID,
    NOT ISNULL(avatars.avatar) AS avatar,
    gebruikers2.gebruikersnaam,
    gebruikers2.email,
    DATE_FORMAT(reacties2.datum, '%d-%m-%Y %H:%i') as tijd,
    bericht
FROM
    reacties2
 LEFT JOIN
    gebruikers2
ON
    gebruikers2.id = reacties2.gebruikersID
 LEFT JOIN
    avatars
ON
    avatars.gebruikersID = gebruikers2.id
WHERE
    reacties2.spelID = $id
ORDER BY
    reacties2.id DESC
 LIMIT   
    $start,$max

Kortom, als avatars.avatar niet leeg is (NOT NULL is) dan krijgt avatar (AS avatar) een waarde. Ik neem aan dat je PHP gebruikt? Dan doe je in PHP iets als:

PHP:

$query = "SELECT
    reacties2.id as reactieID,
    NOT ISNULL(avatars.avatar) AS avatar,
    gebruikers2.gebruikersnaam,
    gebruikers2.email,
    DATE_FORMAT(reacties2.datum, '%d-%m-%Y %H:%i') as tijd,
    bericht
FROM
    reacties2
 LEFT JOIN
    gebruikers2
ON
    gebruikers2.id = reacties2.gebruikersID
 LEFT JOIN
    avatars
ON
    avatars.gebruikersID = gebruikers2.id
WHERE
    reacties2.spelID = $id
ORDER BY
    reacties2.id DESC
 LIMIT   
    $start,$max";
$result = mysql_query($query);
while (list($id, $avatar) = mysql_fetch_array($result)) {
  if ($avatar == "") { // of NULL (weet niet of dat werk :S)
   $avatar = ""; // beetje overbodig, maar het gaat om het idee
  } else {
   $avatar = "[img]\"".$avatar."\"[/img]";
  }
}

[ Voor 9% gewijzigd door zeroxcool op 01-07-2003 23:54 ]

[ACM]

NOT ISNULL(avatars.avatar) AS avatar,

Levert dat niet null op als er geen avatar is

Wat is dan de toegevoegde waarde ervan?
* ACM snapt het gedoe sowieso niet, die if _is_ het probleem echt niet (hooguit die typo met die > ), de toevoeging van de left join lijkt me meer een potentiele problemenveroorzaker.

[zeroxcool]

ACM schreef op 02 July 2003 @ 00:12:
[...]

Levert dat niet null op als er geen avatar is

Wat is dan de toegevoegde waarde ervan?
* ACM snapt het gedoe sowieso niet, die if _is_ het probleem echt niet (hooguit die typo met die > ), de toevoeging van de left join lijkt me meer een potentiele problemenveroorzaker.

Als avatar een BLOB field was met daarin de image data dan had het wel een toegevoegde waarde. Heb weer niet verder gekeken dan m'n neus lang is .

* zeroxcool weet het dan ook niet meer...

[OZ-Gump]

Ik ga even iets heel raars roepen, maar maak van je IF eens een IIF, of een CASE WHEN A = B THEN C ELSE D End. Volgens mij gaan ze daar een stuk relaxter mee om. Tenminste, dat werkt bij mij altijd vlekkeloos. Ik weet natuurlijk niet of dat je probleem oplost, maar het is het proberen waard dacht ik!

De Case werkt overigens alleen in de Query Analyzer (of hoe heet dat ding ook alweer.....?

[ Voor 21% gewijzigd door OZ-Gump op 02-07-2003 01:19 ]

[ACM]

IIF bestaat niet in mysql...

* ACM denkt dat het weinig nut heeft nog langer in dit topic te speculeren.
De topicstarter heeft al een tijdje niet meer gereageerd en zonder zijn input kunnen we weinig...

[OZ-Gump]

ACM: je hebt gelijk wat betreft het nut. Maareh... heb ik dan ergens gemist dat dit over MySQL gaat?

Anyhow, zonder TS inderdaad weinig nut meer...

[ACM]

Dat is nergens gezegd nee, maar als je naar de elementen uit de query kijkt moet het wel mysql zijn.
Die IF, die CONCAT, die LIMIT, het feit dat de LEFT JOINs verkeerd om mogen zitten.

[OZ-Gump]

Zoveel MySQL-ervaring heb ik dan weer niet...

[Annie]

Joehoe, TS, where art thou?
Anyway, speculatie is my middle name, dus:

Zoals ACM aangaf moet je eens gaan kijken naar de LEFT JOIN op de avatars. Worden er bijvoorbeeld indices gebruikt? Kan je wat spelen met de join-criteria zodat gegevens wat effectiever opgehaald worden (ik weet niet in hoeverre de sql parser cq. optimiser van mysql zich daar uberhaupt wat van aantrekt).
Bijvoorbeeld iets als:

SQL:

SELECT
    reacties2.id as reactieID,
    CONCAT(
        '[img]\"',
        avatars.avatar,
        '\"[/img]
    ) as avatar,
    gebruikers2.gebruikersnaam,
    gebruikers2.email,
    DATE_FORMAT(reacties2.datum, '%d-%m-%Y %H:%i') as tijd,
    bericht
FROM
    reacties2
 LEFT JOIN
    gebruikers2
ON
    (gebruikers2.id = reacties2.gebruikersID AND reacties2.spelID = $id)
 LEFT JOIN
    avatars
ON
    avatars.gebruikersID = gebruikers2.id
ORDER BY
    reacties2.id DESC
 LIMIT   
    $start,$max

[ACM]

Ik denk dat jouw query niet helemaal correct is, want nu join je aan _alle_ reacties die gebruikers die een overeenkomstige id hebben en waarbij er een spelid X is

Verder meende ik dat een left join zo moet:
left join avatars on gebruikers2.id = avatars.gebruikersID

en ik kan me voorstellen dat er voor elke reactie een gebruiker _moet_ zijn en dan is de left join eigenlijk niet helemaal het ideale middel om de reacties en de gebruikers aan elkaar te plakken

[ Voor 49% gewijzigd door ACM op 02-07-2003 21:29 ]

[Annie]

ACM schreef op 02 juli 2003 @ 21:27:
Ik denk dat jouw query niet helemaal correct is, want nu join je aan _alle_ reacties die gebruikers die een overeenkomstige id hebben en waarbij er een spelid X is

offtopic:
Mja, had geen zin om heel erg diep na te denken