[MySQL] Query geeft ander resultaat dan wat er in DB staat?

[ThinkPad]

Ik heb een database waarin een Arduino elke 5 min. temperaturen wegschrijft. Met die data wil ik wat gaan doen uiteraard.

Maar ik kom er met de queries niet helemaal uit.

Ik meet op dit moment met 3 sensoren, dit zijn de nieuwste waardes van elke sensor:


Als ik echter de nieuwste meting van één sensor wil ophalen (de onderste in dit geval), met query

SQL:

SELECT celsius, MAX(id) FROM temperature WHERE sensor = '28 92 19 a8 04 00 00 65'

Dan krijg ik als resultaat '31.4' terug ipv '36.7'.... Hoe kan dat!??

datatype van de cel is DECIMAL(3,1), voorheen VARCHAR(30), maar DECIMAL leek me beter. Met VARCHAR had ik het probleem echter ook al.

Enige wat misschien wel een probleem zou kunnen zijn, is dat MySQL bovenaan laat zien:

De huidige selectie bevat geen unieke kolom. Functies zoals rasterbewerkingen, checkboxen, Bewerken, Kopiëren en Verwijderen, zijn niet beschikbaar.

Maar ik heb het veld 'id' gewoon als PK ingesteld....

[ Voor 5% gewijzigd door ThinkPad op 18-07-2014 17:03 ]

[Koetjeboe]

Je wilt dit:

code:

SELECT id as LATEST, celsius FROM `temperature`
WHERE `sensor` = '28 92 19 a8 04 00 00 65' ORDER BY id DESC LIMIT 1

Nu haal je gewoon de MAX(id) op en een celcius, niet de bijbehorende celcius.

[ Voor 21% gewijzigd door Koetjeboe op 18-07-2014 16:59 ]

[ThinkPad]

Dankjewel, dat lijkt inderdaad wel te werken.

Die foutmelding snap ik ook niet, als ik gewoon een PK heb ingesteld. Met jouw query zie ik die foutmelding namelijk ook.

[ Voor 15% gewijzigd door ThinkPad op 18-07-2014 17:02 ]

[Koetjeboe]

Ja, zie dit stukje:

Nu haal je gewoon de MAX(id) op en een celcius, niet de bijbehorende celcius.

Je vraagt om celcius maar geeft nergens in de WHERE of ORDER aan welke je dan wilt, dan krijg je (waarschijnlijk) gewoon de eerste.

Ten aanzien van de foutmelding, kun je 'SHOW COLUMNS FROM temperature' laten zien, klinkt toch alsof je geen unieke index op de id kolom hebt.

[ Voor 8% gewijzigd door Koetjeboe op 18-07-2014 17:06 ]

[Gtoniser]

Die foutmelding is van phpmyadmin (wat wel vaker rare dingen zegt), niet van mysql.

[ThinkPad]

'SHOW COLUMNS FROM temperature' geeft dit:

code:

+---------+--------------+------+-----+-------------------+----------------+
| Field   | Type         | Null | Key | Default           | Extra          |
+---------+--------------+------+-----+-------------------+----------------+
| id      | int(11)      | NO   | PRI | NULL              | auto_increment |
| event   | timestamp    | NO   | MUL | CURRENT_TIMESTAMP |                |
| sensor  | varchar(30)  | NO   |     | NULL              |                |
| celsius | decimal(3,1) | NO   |     | NULL              |                |
+---------+--------------+------+-----+-------------------+----------------+
4 rows in set (0.00 sec)

[ Voor 3% gewijzigd door ThinkPad op 18-07-2014 17:18 ]

[RobIII]

ThinkPadd schreef op vrijdag 18 juli 2014 @ 16:55:
Als ik echter de nieuwste meting van één sensor wil ophalen (de onderste in dit geval), met query

SQL:

SELECT celsius, MAX(id) 
FROM temperature 
WHERE sensor = '28 92 19 a8 04 00 00 65'

Hoe werkt dat GROUP BY nu eigenlijk?
Lang verhaal kort: Als je aggregates gebruikt moet je een GROUP BY gebruiken. En omdat MySQL een <bliep>-product is staat 'ie dergelijke queries doodleuk toe zonder je op 't matje te roepen en verzint zelf maar een "group by" die voor hem goed uit komt Elk ander (fatsoenlijk) RDBMS had je query uitgelachen en 't vertikt 'm uit te voeren (Ik geloof overigens dat nieuwe(re) versies van MySQL en/of een strict mode switch/ini-entry wel dergelijke queries alsnog afschieten als incorrect.)

Die melding van "De huidige selectie bevat geen unieke kolom..." die je krijgt is ook doodlogisch: omdat het resultaat van de query waar je op dat moment naar zit te kijken (i.p.v. de tabel met de data) geen ID (of beter: PK) bevat waardoor bij een wijziging bijvoorbeeld in die (query resultaat)-tabel niet bepaald kan worden welk record correspondeert met 't daadwerkelijke record in de DB. Als je er een ID bij select(eert) is 't opgelost; bij een edit (of delete of...) van een rij weet PHPMyAdmin namelijk, "on-ambigu", welk record bedoeld wordt.

Even versimpeld: Ik heb een tabel:

code:

id  name        karma
--  ----------  -------
1   Janssen     291163
2   Klaassen    132
3   De wit      49887
4   Janssen     3789

(Note de 2 Janssen's )

Ik laat er de volgende query op los:

SQL:

select name, karma from mytable

Dat resulteert in:

code:

name        karma
----------  -------
Janssen     291163
Klaassen    132
De wit      49887
Janssen     3789

Vervolgens klik ik in de interface op rij 4 (Janssen met karma 3789) en verwijder / bewerk die rij. Wat moet PHPMyAdmin nu sturen naar MySQL?

SQL:

update mytable set karma = 9999 where name = 'janssen'
--of
delete from mytable where name = 'janssen'

?

Dat gaat niet goed komen, wel?

Een slimmerik hier op kantoor merkte op dat de interface een query als "update mytable set karma = 9999 where name = 'janssen' and karma = 9789" zou kunnen sturen waarna ik die collega om z'n oren sloeg met de opmerking dat er natuurlijk geen garantie is dat er nog een record is met id 289037 (bij wijze van) die 'toevallig' ook Janssen heet en een karma van 9789 zou hebben. Het had wél gekund (en je had de melding niet gezien) als de combinatie [name, karma] een unique constraint had gehad (wat natuurlijk onzinnig zou zijn in geval van [name, karma] maar bijv. wel had gewerkt in geval van [name, kenteken] om maar wat te roepen.

Het werkt wél (en je krijgt die melding niet) als je ID erbij select:

SQL:

select id, name, karma from mytable

PHPMyAdmin weet dan bij een edit / delete dat 'ie de volgende query moet sturen:

SQL:

update mytable set karma = 9999 where id = 4
--of
delete from mytable where id = 4

ID is namelijk een uniek gegeven waarop een rij geïdentificeerd kan worden (de PK) en ID is beschikbaar in de resultset. Dat is bij de eerdere query niet het geval.

[ Voor 104% gewijzigd door RobIII op 18-07-2014 18:25 ]

[incaz]

Die foutmelding is een beetje cryptisch, maar volgens mij komt het er gewoon op neer dat je geen opgehaalde records kunt bewerken. Nooit - geen deel van de standaard. Wil je dat, dan moet je zelf een update-statement bouwen.

Nou zijn er veel tools die dit makkelijk maken, en die hebben dan een handigheidje dat ze als je de tabel bekijkt zonder verdere zaken, het updatestatement wel eenvoudig te creeren is, en dus lijkt het alsof je de data rechstreeks kunt bewerken. Achter de schermen doet het dan waarschijnlijk een

SQL:

UPDATE tbl SET field = newvalue WHERE id = ( oldquery )

In dit geval, doordat het een statement is dat door de tijd verschillende dingen op kan halen, zegt je tooltje: daar ga ik mijn vingers niet aan branden.

Maar heel misschien snapt 'ie het bv weer wel als je de kolom gewoon id laat heten ipv 'latest'? Je weet het soms nooit met die tooltjes.

[RobIII]

incaz schreef op vrijdag 18 juli 2014 @ 19:21:

Of je leest de post boven je even

[ThinkPad]

Bedankt voor de uitgebreide uitleg RobIII Het is helder nu

[incaz]

RobIII schreef op vrijdag 18 juli 2014 @ 19:50:
[...]

Of je leest de post boven je even

Sorry, die vond ik dusdanig omslachtig dat ik ergens halverwege afgehaakt ben, en het maar in eigen woorden heb opgeschreven. Ik kon bv niet helemaal achterhalen waar die karma nou vandaan kwam, en het leek bovendien vooral uit te leggen waarom de eerste query de foutmelding gaf, terwijl ook de tweede query die melding geeft.

[RobIII]

incaz schreef op vrijdag 18 juli 2014 @ 21:04:
[...]


Sorry, die vond ik dusdanig omslachtig dat ik ergens halverwege afgehaakt ben, en het maar in eigen woorden heb opgeschreven.

Alleen kloppen je eigen woorden niet. Ik kon/kan het niet makkelijk(er) onder woorden brengen, granted, maar het klopt iig

[incaz]

Kun je uitleggen wat er niet aan klopt? Ik zie niet helemaal waar het de mist in gaat. Wellicht de warmte maar...

Hmm, bij teruglezen heb ik in elk geval niet duidelijk genoeg gemaakt dat ik alleen maar een suggestie wilde opperen voor de foutmelding bij de tweede query en niet voor het oorspronkelijke probleem. Maar ik weet niet of ik daarnaast nog een andere denkfout maak.

[Arie-]

Het gaat niet om het updaten van een record, hij selecteert een record op basis van een verkeerde unieke eigenschap.
Wat wil TS: de laatste temperatuurmeting van sensor x.
Wat vraagt TS aan de database: een temperatuurmeting van sensor x, zonder constraint welke meting dat dan zou moeten zijn.

Het screenshot wat geplaatst is toont slechts drie rijen, maar niets zegt dat er vijf minuten eerder niet ook een record is met een temperatuur, gemeten door exact dezelfde sensor als een van de drie die daar staat. Voor wat de TS wil, wordt er een verkeerde query gebruikt. Een oplossing wordt aangedragen:
- selecteer alle temperatuur metingen,
--sorteer deze op moment van meten waarbij de jongste (meest recente) bovenaan staat
--pak van deze selectie de eerste rij.

[ThinkPad]

Exact, niets meer aan toe te voegen

[RobIII]

incaz schreef op vrijdag 18 juli 2014 @ 21:34:
Kun je uitleggen wat er niet aan klopt? Ik zie niet helemaal waar het de mist in gaat. Wellicht de warmte maar...

Nou; ok

Alleerst: mijn eerste alinea legt uit wat er mankeert aan z'n query (los van de limit, order etc. die 'ie nodig heeft en wat Koetjeboe al had verteld) en staat los van het hele verhaal over de "melding" die hij krijgt die ik in de rest van mijn post verklaar. Dus dat even allemaal terzijde.

incaz schreef op vrijdag 18 juli 2014 @ 19:21:
Die foutmelding is een beetje cryptisch, maar volgens mij komt het er gewoon op neer dat je geen opgehaalde records kunt bewerken. Nooit - geen deel van de standaard.

Dat is al totale onzin; a) je haalt geen records op (als in: ze staan nog steeds gewoon in de DB, je krijgt gewoon resultaten die de UI weergeeft _{(ik vermoed PHPMyAdmin in dit geval, maar eender welke tool / GUI om je DB een beetje te benaderen)}) en b) geen idee wat "de standaard" ermee te maken heeft

incaz schreef op vrijdag 18 juli 2014 @ 19:21:
Wil je dat, dan moet je zelf een update-statement bouwen.

Dat moet je altijd... Ongeacht of je ze "opgehaald hebt" of niet.

Linksom of rechtsom is je hele eerst alinea in die post al... mja... raar

incaz schreef op vrijdag 18 juli 2014 @ 19:21:
Nou zijn er veel tools die dit makkelijk maken, en die hebben dan een handigheidje dat ze als je de tabel bekijkt zonder verdere zaken, het updatestatement wel eenvoudig te creeren is

Niet alleen voor een 'tabel' (wat ook niets anders is dan een select * from mytable (bij wijze van) onder water). Veel (zo niet alle?) tools kunnen ook gewoon resultsets bewerken waar een where-clause, group-by, order etc. op toegepast zijn. Maar, en dat is de crux, die tools moeten wel de rijen uit die resultset kunnen herleiden naar het eigenlijke record. En dat kan alleen maar als er een "ID" (of die nou "ID" heeft of "Appelflap", het moet uniek zijn, liefst een PK) in die rij van de resultset zit.

incaz schreef op vrijdag 18 juli 2014 @ 19:21:
en dus lijkt het alsof je de data rechstreeks kunt bewerken. Achter de schermen doet het dan waarschijnlijk een

SQL:

UPDATE tbl SET field = newvalue WHERE id = ( oldquery )

Niks oldquery; gewoon ...where ID = <selected_row_id>. Maar dan moet die ID dus wel "mee ge-select" zijn.

(Sowieso geeft "oldquery", waar je op dat moment tegen aan zit te kijken in je UI, een resultset (0, 1 of meerdere rijen) en niet een ID*. Scalar vs. table)

* tenzij je select x from y where z hebt gedaan waar je maar 1 rij met 1 veld terugkrijgt, dat is dan table én scalar

incaz schreef op vrijdag 18 juli 2014 @ 19:21:
In dit geval, doordat het een statement is dat door de tijd verschillende dingen op kan halen, zegt je tooltje: daar ga ik mijn vingers niet aan branden.

Dat tooltje hoeft niet slimmer te zijn dan: zit er een "uniek iets" in de rij waardoor ik weet met welke rij de geselecteerde rij uit de interface in de eigenlijke tabel correspondeert? Ja? -> Edit controls weergeven. Nee? Edit controls verbergen + melding weergeven dat ik niet genoeg informatie heb om je die controls te laten gebruiken (hence: precies wat TS ziet: een melding dat die controls niet beschikbaar zijn omdat...)

incaz schreef op vrijdag 18 juli 2014 @ 19:21:
Maar heel misschien snapt 'ie het bv weer wel als je de kolom gewoon id laat heten ipv 'latest'?

Onzin; zie een stukkie terug in deze post mijn "appelflap" opmerking.

incaz schreef op vrijdag 18 juli 2014 @ 19:21:
Je weet het soms nooit met die tooltjes.

Er is zat gare meuk in omloop, maar een béétje tool snap ook wel dat 'ie beter even de tabel kan bekijken naar wat de PK is (en die gebruiken) of, eventueel, of er nog andere "unieke zaken" (unique constraint) zijn waarop een rij die in de UI wordt weergegeven gecorreleerd kan worden aan 't eigenlijke record uit de tabel.

[ Voor 6% gewijzigd door RobIII op 18-07-2014 23:15 ]

[incaz]

Dank voor de uitleg.
Dat van die oldquery (scalar vs resultset) is inderdaad fout, mijn excuses.

Maar op andere vlakken geloof ik dat wij elkaar niet gaan vinden, want jij denkt en benadert de zaken gewoon op een andere manier. Een aantal dingen had ik wat zorgvuldiger moeten omschrijven, maar een aantal dingen is ook gewoon een andere manier van benaderen.

De meeste tools kennen overigens wel beperkingen, waarbij de resultset niet te bewerken is als er bv meer dan 1 tabel involved is, zelfs al gaat het om velden van de eerste tabel, met pk.

Maar het laatste, dat klopt dus niet. Want in die laatste query is er een pk-veld, namelijk id. Dus er is geen reden waarom die melding zou moeten verschijnen. En de enige reden die ik kan verzinnen is dat phpmyadmin niet snapt dat 'latest' hetzelfde veld is als id.

[Gomez12]

incaz schreef op zaterdag 19 juli 2014 @ 10:37:
Maar het laatste, dat klopt dus niet. Want in die laatste query is er een pk-veld, namelijk id. Dus er is geen reden waarom die melding zou moeten verschijnen. En de enige reden die ik kan verzinnen is dat phpmyadmin niet snapt dat 'latest' hetzelfde veld is als id.

Er is geen pk-veld. Er is een aggrageted function field (wat in dit geval over een pk-veld gaat en wat vanwege de functie slechts 1 waarde teruggeeft (alhoewel de functie wel meerdere rijen kan opleveren))

In wezen bestaat het resultaat uit de laatste query uit :
celsius kolom uit tabel
aggregated field

En celsius is geen pk dus valt er geen vaste koppeling te maken.

In theorie valt er wel na te gaan of de aggregated function over een unique field gaat en of de aggregated function maar 1 resultaat heeft wat ook nog eens de waarde van een unique field is (anders heb je last met sum() etc) maar dat vereist veel additioneel werk wat de snelheid niet ten goede komt voor kleine extra functionaliteit.
Als ik uit een sum(id) de waarde 3 krijg valt dat dan terug te mappen naar record-id 3 of naar record-id 1 en 2?

Een tool die zou reageren op namen ipv gewoon de db-structuur uitlezen kan je direct de prullenbak inmieteren, zeker met kolommen als id (zo heet er eigenlijk nooit 1 in mijn tabellen) want id is over het algemeen een heel slechte naam of je moet van aliassen houden.

[incaz]

In

SQL:

SELECT id as LATEST, celsius FROM `temperature`
WHERE `sensor` = '28 92 19 a8 04 00 00 65' ORDER BY id DESC LIMIT 1

staat toch echt gewoon een id-veld hoor, en geen aggregate te bekennen.

En voor de goede orde: in HeidiSql kan de rij dan ook bewerkt worden. De TS geeft echter aan dat ook op die query de melding komt dat er geen pk is om de bewerking mee te doen.

[RobIII]

Dan klopt het verhaal toch nog steeds Alleen is de tool van TS (schijnbaar) niet slim genoeg om met aliassen overweg te kunnen (afgaand op de screenshot PHPMyAdmin?).

[incaz]

Ik ontken toch ook niet dat het verhaal klopt
Het heeft alleen niets met mijn opmerking te maken - daar staat namelijk wel een pk-veld en geen aggregate.

[ Voor 55% gewijzigd door incaz op 20-07-2014 21:41 ]

[Gomez12]

incaz schreef op zondag 20 juli 2014 @ 21:40:
Het heeft alleen niets met mijn opmerking te maken - daar staat namelijk wel een pk-veld en geen aggregate.

Tip : Quoten...

Als iemand het heeft over laatste query ga ik omhoog scrollen en dan kom ik in RobIII zijn post een query tegen...

[incaz]

Tip: lezen en niet slechts reageren op het laatste. Want ik schreef al

Hmm, bij teruglezen heb ik in elk geval niet duidelijk genoeg gemaakt dat ik alleen maar een suggestie wilde opperen voor de foutmelding bij de tweede query en niet voor het oorspronkelijke probleem.

(Maar goed, een alternatief is om niet uit te gaan van 'we gaan mensen wel eens wijzen op hun stommiteiten' maar juist proberen te achterhalen wat mensen wel bedoelen. Deze manier maakt de discussie erg hakketakkerig en weinig constructief. Ik heb er zelf aan meegedaan, maar ik moet het niet doen, het maakt de dingen eigenlijk alleen maar vervelend.)

[ThinkPad]

Even dit topic weer kicken, ik zit weer met hetzelfde probleem

Ik heb de query

SQL:

SELECT MAX(`huidig_verbruik`) as E_HOOGSTE_VANDAAG, TIME_FORMAT(time,"%H:%i") 
FROM readings 
WHERE DATE(time) = CURRENT_DATE GROUP BY huidig_verbruik LIMIT 1

Maar die geeft niet het gewenste resultaat.
Wat ik wil zien is:

2038 12:15

Maar hij komt alleen met 80 12:26

Ik heb dit hele stuk: Programming FAQ - SQL - GROUP BY doorgelezen en snap het principe, maar het is mij niet duidelijk op welke kolommen ik de group by moet doen GROUP BY op 'huidig_verbruik, time' helpt niet.

Ik heb de kolommen:
id
time
laag_tarief
hoog_tarief
huidig_verbruik
gas

[ Voor 18% gewijzigd door ThinkPad op 23-08-2014 14:25 ]

[RobIII]

Group by doe je op alle non-aggregates (lees: alles wat niet in een sum/max/avg/... staat)

[ThinkPad]

Maar als ik de GROUP BY op 'id' (die ook in de SELECT meeneem ) of op 'time' doe werkt het nogsteeds niet...

[ Voor 27% gewijzigd door ThinkPad op 23-08-2014 14:53 ]

[RobIII]

ThinkPadd schreef op zaterdag 23 augustus 2014 @ 14:50:
Maar als ik de GROUP BY op 'id' (die ook in de SELECT meeneem ) of op 'time' doe werkt het nogsteeds niet...

Ik had duidelijker moeten zijn:

RobIII schreef op zaterdag 23 augustus 2014 @ 14:30:
Group by doe je op alle non-aggregates in je select/where (lees: alles wat niet in een sum/max/avg/... staat)

Als je id niet selecteert hoeft 'ie ook niet in je group by natuurlijk.

[.oisyn]

Het is inmiddels al een maand geleden, maar kan iemand mij uitleggen waarom hij in de startpost die resultaten geeft als hij een willekeurige temperatuur opvraagt uit een lijst met alle rijen waarvan de primary key een bepaalde waarde heeft (ergo, de lengte van die lijst is 0 of 1)?

.edit: oh wacht, een WHERE filtert pas na een aggregate, niet ervoor.

[ Voor 12% gewijzigd door .oisyn op 23-08-2014 16:21 ]

[ThinkPad]

Group by doe je op alle non-aggregates in je select/where (lees: alles wat niet in een sum/max/avg/... staat)

Op welke kolom moet ik dan de 'GROUP BY' doen in mijn situatie

Als ik de GROUP BY op 'time' doe dan klopt het resultaat namelijk niet...

[.oisyn]

Je wilt helemaal geen GROUP BY in deze situatie, want er is niets waar je op wilt groeperen. Je wilt gewoon het record ophalen waarvoor het maximale gebruik het grootst is, met de tijd daarbij.

De oplossing van Koetjeboe is ook hier van toepassing. Je kunt alle records sorteren op huidig_verbruik van hoog naar laag, en dan alleen het eerste resultaat terugvragen.

Een andere oplossing wordt wellicht evident als je het eerst in woorden omschrijft: geef alle rijen terug (want er is er mogelijk meer dan 1) waarvoor het verbruik maximaal is. Je komt dan op iets als:

SQL:

SELECT huidig_verbruik as E_HOOGSTE_VANDAAG, TIME_FORMAT(time,"%H:%i") 
FROM readings 
WHERE DATE(time) = CURRENT_DATE AND huidig_verbruik =
    (SELECT MAX(huidig_verbruik) FROM readings WHERE DATE(time) = CURRENT_DATE)

Oftewel: eerst het maximale verbruik ophalen, en daarna alle records erbij zoeken die daaraan voldoen.

---

Om even terug te komen op mijn eerdere opmerking:

.oisyn schreef op zaterdag 23 augustus 2014 @ 16:19:
.edit: oh wacht, een WHERE filtert pas na een aggregate, niet ervoor.

Nee, natuurlijk is dat niet zo . Mijn vergissing kwam vooral omdat de sensor niet de PK is maar een FK, en dus niet uniek in die tabel.

[ Voor 23% gewijzigd door .oisyn op 24-08-2014 15:06 ]

[ThinkPad]

.oisyn schreef op zondag 24 augustus 2014 @ 15:03:
Je wilt helemaal geen GROUP BY in deze situatie, want er is niets waar je op wilt groeperen. Je wilt gewoon het record ophalen waarvoor het maximale gebruik het grootst is, met de tijd daarbij.

De oplossing van Koetjeboe is ook hier van toepassing. Je kunt alle records sorteren op huidig_verbruik van hoog naar laag, en dan alleen het eerste resultaat terugvragen.

Een andere oplossing wordt wellicht evident als je het eerst in woorden omschrijft: geef alle rijen terug (want er is er mogelijk meer dan 1) waarvoor het verbruik maximaal is. Je komt dan op iets als:

SQL:

SELECT huidig_verbruik as E_HOOGSTE_VANDAAG, TIME_FORMAT(time,"%H:%i") 
FROM readings 
WHERE DATE(time) = CURRENT_DATE AND huidig_verbruik =
    (SELECT MAX(huidig_verbruik) FROM readings WHERE DATE(time) = CURRENT_DATE)

Oftewel: eerst het maximale verbruik ophalen, en daarna alle records erbij zoeken die daaraan voldoen.

---

Om even terug te komen op mijn eerdere opmerking:

[...]

Nee, natuurlijk is dat niet zo . Mijn vergissing kwam vooral omdat de sensor niet de PK is maar een FK, en dus niet uniek in die tabel.

Thanks

Eerst sorteren op hoogste (waarbij dag = vandaag) werkt idd ook. En dan een 'LIMIT 1' erbij om hoogste te krijgen. Toch stom dat je dat op het moment zelf niet bedacht krijgt, achteraf is het heel logisch.