[MySQL] Records ouder dan 30 minuten verwijderen

[Verwijderd]

Beste mensen,


Ik zoek nu al een tijdje naar een oplossing van mijn probleem, maar de SQL refrence en de topics hier konden mij niet echt opweg helpen.

Ik heb een veld 'last' van het type DATETIME. Als er in dit veld een waarde staat van 30 minuten geleden wil ik hem weggooien, maar, dat bleek nog niet zo eenvoudig als het klinkt.

Tot noch toe heb ik dit, maar hiermee krijg ik een SQL error

DELETE FROM proj_invalidLogin WHERE last < SUBDATE(NOW() - 30 MIN)

Zou iemand mij hiermee kunnen helpen?

[SchizoDuckie]

cut-n-paste van mysql.com reference:

SQL:

SUBTIME(expr1,expr2)

SUBTIME() returns expr1 – expr2 expressed as a value in the same format as expr1. expr1 is a time or datetime expression, and expr2 is a time expression.

mysql> SELECT SUBTIME('1997-12-31 23:59:59.999999','1 1:1:1.000002');
        -> '1997-12-30 22:58:58.999997'
mysql> SELECT SUBTIME('01:00:00.999999', '02:00:00.999998');
        -> '-00:59:59.999999'

http://dev.mysql.com/doc/...e-and-time-functions.html

[Psychokiller]

Volgens mij gebruik ik in onze Admin ergens TimeDiff() in combinatie met MINUTE():

DELETE FROM proj_invalidLogin WHERE MINUTE(TimeDiff( NOW(), last )) > 30

Kom er nu echter achter dat Minute niet slim is om te gebruiken, omdat die natuurlijk niet het veschil in minuten geeft maar de zoveelste minuut.

Ik denk dat het hiermee beter gaat werken:
DELETE FROM proj_invalidLogin WHERE DATE_ADD(last , INTERVAL 30 MINUTE) < NOW();

[Voutloos]

Verwijderd schreef op dinsdag 18 december 2007 @ 21:04:
Tot noch toe heb ik dit, maar hiermee krijg ik een SQL error

DELETE FROM proj_invalidLogin WHERE last < SUBDATE(NOW() - 30 MIN)

Je krijgt een syntax error en syntax errors zijn altijd eenvoudig op te lossen door de documentatie nogmaals te lezen. Het is SUBDATE(date,INTERVAL expr unit).

En als je die funcite op die manier gebruikt, gaat 'When invoked with the INTERVAL form of the second argument, SUBDATE() is a synonym for DATE_SUB()' op en kan je imo beter meteen DATA_SUB schrijven.

[ Voor 21% gewijzigd door Voutloos op 18-12-2007 21:51 ]

[BalusC]

Voutloos schreef op dinsdag 18 december 2007 @ 21:49:
En als je die funcite op die manier gebruikt, gaat 'When invoked with the INTERVAL form of the second argument, SUBDATE() is a synonym for DATE_SUB()' op en kan je imo beter meteen DATA_SUB schrijven.

Waarom geen DATE_SUB()?

[Maasluip]

Is het niet zo dat in MySQL (net als in andere fatsoenlijke talen) een hele dag 1 is, 12 uur 0,5 enz.? Dan kun je gewoon now()-0,0208333 doen.

[DigiK-oz]

Maasluip schreef op woensdag 19 december 2007 @ 07:39:
Is het niet zo dat in MySQL (net als in andere fatsoenlijke talen) een hele dag 1 is, 12 uur 0,5 enz.? Dan kun je gewoon now()-0,008333 doen.

Tja, als dat al zo is, dan heb je ten eerste niet EXACT een half uur (je weet niet hoe belangrijk dat in dit geval is) en ten tweede vraag je je volgend jaar, als je de code moet gaan bijwerken, af wat er staat. Wordt er niet echt (echt niet) leesbaarder op.

[Confusion]

Maasluip schreef op woensdag 19 december 2007 @ 07:39:
Is het niet zo dat in MySQL (net als in andere fatsoenlijke talen) een hele dag 1 is, 12 uur 0,5 enz.?

Nee, in fatsoenlijke RDBMS'en als DB2 kan je juist handige dingen zeggen als:

code:

WHERE date BETWEEN CURRENT TIMESTAMP - 5 DAYS AND CURRENT TIMESTAMP - 1 DAY - 1 HOUR - 30 MINUTES.

[Janoz]

Maasluip schreef op woensdag 19 december 2007 @ 07:39:
Is het niet zo dat in MySQL (net als in andere fatsoenlijke talen) een hele dag 1 is, 12 uur 0,5 enz.? Dan kun je gewoon now()-0,008333 doen.

Niet elke dag is 24 uur..

[Voutloos]

BalusC schreef op woensdag 19 december 2007 @ 07:18:
[...]
Waarom geen DATE_SUB()?

Stomme typo, de goed gespelde functienaam staat natuurlijk letterlijk in de quote.

Maasluip schreef op woensdag 19 december 2007 @ 07:39:
Is het niet zo dat in MySQL (net als in andere fatsoenlijke talen) een hele dag 1 is, 12 uur 0,5 enz.? Dan kun je gewoon now()-0,008333 doen.

Ik wil niet eens weten of het kan, want DATE_SUB(NOW(), INTERVAL 10 MIN) is gewoon veel leesbaarder en minder foutgevoelig.

En iets waar ik laatste tijd steeds meer mensen in zie trappen: rekenen met datums en tijden is vaak niet zo triviaal als men denkt; onderschat het niet en wees blij met standaard aanwezige functies.

[LDenninger]

Maasluip schreef op woensdag 19 december 2007 @ 07:39:
Is het niet zo dat in MySQL (net als in andere fatsoenlijke talen) een hele dag 1 is, 12 uur 0,5 enz.? Dan kun je gewoon now()-0,008333 doen.

+1 award voor de meest wanstaltige manier om iets op te lossen.

Als je dit op je werk zou doen zou ik je voordragen om een paar salarisschalen omlaag te gaan

[Maasluip]

Sloompie schreef op woensdag 19 december 2007 @ 07:51:
[...]

Tja, als dat al zo is, dan heb je ten eerste niet EXACT een half uur (je weet niet hoe belangrijk dat in dit geval is) en ten tweede vraag je je volgend jaar, als je de code moet gaan bijwerken, af wat er staat. Wordt er niet echt (echt niet) leesbaarder op.

Dan doe je 30/1440. Als dat niet leesbaar is moet je je serieus afvragen hoe intelligent de programmeur is.

Of is het geen standaard kennis dat er 1440 minuten in een dag zitten?

[Janoz]

Nogmaals, niet in elke dag zitten 1440 minuten. Daarnaast, waarom blijf je zo koppig vasthouden aan die 'magic numbers' terwijl er keurige beschrijvende naamgeving voor bestaat? Persoonlijk twijfel ik aan de intelligentie van de programmeur wanneer hij dateTime - 30/1440 blijft gebruiken wanneer hem al is verteld dat je ook DATE_SUB(dateTime , INTERVAL 30 MINUTE) kunt gebruiken.

[Voutloos]

Maasluip schreef op donderdag 20 december 2007 @ 07:48:
Dan doe je 30/1440. Als dat niet leesbaar is moet je je serieus afvragen hoe intelligent de programmeur is.

Van hetzelfde kaliber:
Als iemand 'INTERVAL 30 MINUTE' niet leesbaarder vindt dan '- 30/1440' moet je je serieus afvragen hoe intelligent die persoon is.

Met een klein aantal minuten rekenen valt vaak nog mee, maar gebruik gewoon altijd DATE_SUB. Dan heb je ook minder kans dat iemand opeens zo'n sommetje met een groter interval gaat maken en daarmee wel bugs introduceert.

[Maasluip]

Janoz schreef op donderdag 20 december 2007 @ 08:04:
Nogmaals, niet in elke dag zitten 1440 minuten.

Ik ken geen enkele dag die dat niet heeft. Ik ken wel dagen die 1 seconde meer hebben, maar dat komt maximaal 2 keer per jaar voor (en gemiddeld de laatste jaren minder dan 1 keer per jaar).

[Voutloos]

Wintertijd/zomertijd.

Dat tezamen met tijdzones, schrikkeljaren, andere kalendertypes, verschillend aantal dagen per maand enz. enz. leidt dus naar mijn eerdere opmerking over het onderschatten van hoe moeilijk het is om met datums en tijden te rekenen.

[ Voor 83% gewijzigd door Voutloos op 20-12-2007 09:58 ]

[Confusion]

Maasluip schreef op donderdag 20 december 2007 @ 07:48:
Of is het geen standaard kennis dat er 1440 minuten in een dag zitten?

Nee, dat weet ik niet uit mijn hoofd en aangezien mensen zich regelmatig verbazen over de getallen die ik wel uit mijn hoofd weet, denk ik niet dat dat standaard kennis is. Sowieso schrijf ik dat altijd als 60*24, omdat iedereen dan kan zien waar het getal vandaan komt. Als ik een buffer van 4K aanmaak, dan is dat ook een char[4 * 1024].

[Maasluip]

Ach ja, dat klopt.
Maar je datum/tijdfuncties moeten ook maar bugfree en zomer/wintertijd aware zijn. En in het verleden heb ik al vaak genoeg met van die functies gewerkt die dat niet zijn

Overigens is het wel de enige methode in Oracle die werkt. Oracle heeft geen speciale datum/tijdrekenfuncties.

[Creepy]

Ik kom toch echt verschillende zaken tegen voor Oracle, inclusief INTERVAL zelfs:

Bron: http://www.psoug.org/reference/date_func.html
SELECT TO_CHAR(SYSDATE + INTERVAL '10' MINUTE, 'HH:MI:SS')
FROM dual;

Werkt zo te zien pas vanaf versie 9i

[ Voor 7% gewijzigd door Creepy op 20-12-2007 10:26 ]

[Maasluip]

Creepy schreef op donderdag 20 december 2007 @ 10:25:
Ik kom toch echt verschillende zaken tegen voor Oracle, inclusief INTERVAL zelfs:

[...]

Werkt zo te zien pas vanaf versie 9i

Verrek ja. 10g ook.
Maar is niet zomer/wintertijd aware, geeft gewoon tijden tussen 30-03-2008 2:00 en 30-03-2008 3:00 af. Dus daarvoor hoef je die functie niet te gebruiken.

[ATS]

Nu mag ik eerlijk gezegd ook niet hopen dat je database server aan zomer en wintertijd doet. Zo'n ding zet je op UTC, en pas waar dat nodig is reken je UTC om in de juiste locale tijd, inclusief zomer en wintertijd.