[MySQL] SQL syntax-error of phpMyAdmin-bug

funkwurm schreef op dinsdag 26 december 2006 @ 01:50:
Het lijkt er dus ook alsof phpMyAdmin achter de schermen per ongeluk de onvolledige query "SHOW KEYS FROM" naar MySQL stuurt, want zo ziet het er niet uit als ik zelf een typo heb gemaakt.

funkwurm schreef op dinsdag 26 december 2006 @ 01:50:
De oplettende Tweaker is het al opgevallen dat ik nu voor de 3e keer een query-probleem post over hetzelfde forum wat ik aan het bouwen ben, alhoewel de tussenpauzen erg groot zijn. Het is je dan ook vergeven als dit niet onmiddellijk een belletje doet rinkelen

Verwijderd schreef op dinsdag 26 december 2006 @ 14:19:
[...]
Maar in je query vind ik 'SELECT t.id NOT IN' wel heel erg vreemd. Bij mijn weten is dat geen correcte SQL. Misschien dat MySQL er wel chocola van kan (proberen te) maken, maar dan kan je phpMyAdmin niet kwalijk nemen dat 'ie niet overweg kan met dit koeterwaals...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

SELECT
    t.boven,
    t.slot,
    t.id AS topic_id,
    q.titel,
    l.naam,
    MAX(p.id) AS last_post_id,
    q.ma<=g.tijd AS new
FROM
    topic t
    INNER JOIN post p ON p.topic_id=t.id
    INNER JOIN post q ON q.id=last_post_id
    INNER JOIN leden l ON l.id=q.poster_id
    LEFT JOIN gezien g ON g.wat_id=t.id AND g.wat=1 AND g.lid_id=".$iLidId."
WHERE
    t.sub_id=".$iSubId."
GROUP BY
    t.id
ORDER BY
    t.boven,
    t.slot,
    YEAR(q.posted) DESC,
    MONTH(q.posted) DESC,
    t.id,
    last_post_id

[ Voor 9% gewijzigd door OnTracK op 27-12-2006 12:46 ]

funkwurm schreef op dinsdag 26 december 2006 @ 18:42:
Nou AfterLife, ik begrijp dat jij als mijn grootste fan op een alternatief voor mijn SELECT t.id NOT IN-constructie gaat broeden?

[ Voor 12% gewijzigd door Verwijderd op 27-12-2006 00:48 ]

Verwijderd schreef op dinsdag 26 december 2006 @ 21:49:
[...]
Get real. Ik wil best meedenken over je data access, maar wanneer je 4 subselects (waarvan 1 sub-subselect) denkt nodig te hebben, zou ik 's heel erg gaan nadenken over je datamodel. OnTracK geeft al aan hoe 't ook zou kunnen zonder de SQL taal te verkrachten, dus kijk daar 's naar.

edit:
Al smokkelt OnTracK ook nogal: elke kolom die niet in de GROUP BY staat hoort een aggregate te zijn. Voor zover ik weet is MySQL de enige database die dit soort syntax accepteert en dan een 'lucky guess' doet in het resultaat wat 'ie terugstuurt.

Overigens is 't vaak handiger om je queries overzichtelijk te houden en de "bend over backwards" subselects etc. in code (PHP, C#, Java, Delphi, whatever) af te handelen. Wel zo onderhoudbaar, en je hebt dan meer grip op de indexen die je database dan denkt te moeten gebruiken. Bij jouw query zal dat "God zegen de greep" zijn, met een bijbehorende performance...

[ Voor 4% gewijzigd door OnTracK op 27-12-2006 12:42 ]

Verwijderd schreef op woensdag 27 december 2006 @ 13:17:
5 van de 7 kolommen in je SELECT zijn geen onderdeel van de GROUP BY clause en ook niet geaggregeerd. Dat is iets meer dan een beetje smokkelen...
Wanneer je zeker weet dat MySQL niets hoeft te gokken, vertel 'm dat dan ook. Door bv. max(l.naam) te gebruiken i.p.v. l.naam (ook al weet je dat l.naam uniek zal zijn binnen de GROUP BY). Je houdt dan correcte SQL syntax over, en het debugt een stuk beter omdat je geen rekening hoeft te houden met 't feit dat MySQL soms de ogen dicht doet en maar een willekeurige waarde uit de ballenbak graait wanneer de query geen unieke resultaten teruggeeft.

Bij MSSQL, Oracle, DB2, Interbase, PostgreSQL, etc. word je dan genadeloos afgestraft. "multiple rows in a singleton select", etc.

[ Voor 29% gewijzigd door OnTracK op 27-12-2006 14:13 ]

Verwijderd schreef op woensdag 27 december 2006 @ 15:33:
In de 1e regel een komma teveel na l.naam? Of zeg ik nu wat heel doms?

michelzwarts schreef op dinsdag 26 december 2006 @ 10:57:
Als je hem nu gewoon uitvoerd vanuit PHP, dan weet je meteen of het aan PHPMyAdmin ligt.