[PHP/MYSQL] Oude records deleten

[Verwijderd]

Beste,

Ik zit met een redelijk simpel vraagje (naar mijn weten)
Ik wil uit mijn database uit een tabel alle records ouder als 12 uur verwijderen, elke keer als er een record word gemaakt slaat hij dit op met een current_timestamp() (mysql commando).

Ik heb dit al:

PHP:

mysql_query("DELETE FROM `leden_wachtwoordvergeten` WHERE `timestamp`<CURRENT_TIMESTAMP(+12)")
or die(mysql_error());

Echter heb ik het "vage" vermoeden dat dat niet gaat werken
Ik heb dus even een zetje nodig in de goede richting. (Gebruik meestal geen tijd functies enzo, heb al rondgekeken en de mysql handleiding erbij gepakt maar daar kwam ik niet echt wijs uit )


-Vincent

[CodeCaster]

Waarom sla je die dingen op als MySQL timestamp, is een unix timestamp daar niet veel handiger voor?

Dan doe je gewoon

PHP:

mysql_query("DELETE FROM leden_wachtwoordvergeten WHERE timestamp < ". time() - (60*60*12));

[Y0ur1]

waarom tel je er iets bij op? eerder: WHERE timestamp < huidige_timstamp() - (60*60*12). Timestamp is in seconden... De huidige timestamp opvragen mag je zelf opzoeken in de mysql manual.

Kijk trouwens goed uit me de DELETE functie, vooral met de WHERE.

[user109731]

Of zoiets:

SQL:

WHERE timestamp < DATE_SUB(CURRENT_TIMESTAMP(), INTERVAL 12 HOUR);

In de MySQL reference worden deze functies ook prima gedocumenteerd...

[Verwijderd]

@CodeCaster,

Is een php timestamp (time()) niet het zelfde als een mysql timestamp (Current_timestamp())

[Verwijderd]

CodeCaster schreef op donderdag 03 mei 2007 @ 17:06:
Waarom sla je die dingen op als MySQL timestamp, is een unix timestamp daar niet veel handiger voor?

Nee. Opslaan doe je in een native formaat, zodat je gebruik kun maken van de volledige capaciteiten van je DBMS. Het is niet moeilijk om in MySQL hetzelfde te doen, je hoeft alleen even te kijken welke functies je tot je beschikking hebt.
En @TS het is gewoon onzin dat je er niet uit kwam. Je hebt er gewoon niet genoeg moeite voor gedaan om het zelf even uit te zoeken.

[Verwijderd]

@Cheatah,

Toevallig is het zo dat ik het niet kon vinden..
Ik ben niet iemand die snel om hulp vraagt.

Heb ondertussen zelf dit al bedacht:

PHP:

$calc = time() - (12 * 60 * 60); //Huidige tijd - 12 uurtjes
mysql_query("DELETE FROM `leden_wachtwoordvergeten` WHERE `timestamp`>'".$calc."'")
or die(mysql_error());

Ongeveer het zelfde als Codecaster had.
Waarschijnlijk verander ik dit nog in de versie van Codecaster.

[CH4OS]

Verwijderd schreef op donderdag 03 mei 2007 @ 17:14:

PHP:

$calc = time() - (12 * 60 * 60); //Huidige tijd - 12 uurtjes
mysql_query("DELETE FROM `leden_wachtwoordvergeten` WHERE `timestamp`>'".$calc."'")
or die(mysql_error());

Ongeveer het zelfde als Codecaster had.
Waarschijnlijk verander ik dit nog in de versie van Codecaster.

Is het dan niet makkelijker om een MySQL-functie te gebruiken, dan hoeft PHP alles niet voor te kouwen en MySQL kan het zelf ook. (Wat Cheetah dus ook al vertelde )

Overigens zou deze query juist de nieuwe records deleten, de < zou je moeten hebben...

Zie ook: MySQL: Date & Time functions...

Voor zover ik weet is het overigens ook sneller dat als je iets vanuit SQL kan doen, om SQL dat dan ook zelf te laten doen, in plaats dat MySQL dat voorgekouwd krijgt door PHP (of een andere programmeertaal of programma)

[ Voor 20% gewijzigd door CH4OS op 03-05-2007 17:31 ]

[Verwijderd]

Verwijderd schreef op donderdag 03 mei 2007 @ 17:12:
[...]

Nee. Opslaan doe je in een native formaat, zodat je gebruik kun maken van de volledige capaciteiten van je DBMS. Het is niet moeilijk om in MySQL hetzelfde te doen, je hoeft alleen even te kijken welke functies je tot je beschikking hebt.
En @TS het is gewoon onzin dat je er niet uit kwam. Je hebt er gewoon niet genoeg moeite voor gedaan om het zelf even uit te zoeken.

Normaal gesproken heb je gelijk, maar in het geval van MySQL zou ik het niet doen.

Ze hebben nogal wat wijzigingen aangebracht in de werking van het native datum formaat van MySQL, dit maakt het upgraden van het database systeem erg lastig en vaak prijzig.

MySQL gaat aan de andere kant ook erg goed om met unix timestamps, net als PHP.

In de combinatie PHP/MySQL zou ik dus altijd aanraden de unix timestamps te gebruiken en niet het native formaat van MySQL.

[CH4OS]

Verwijderd schreef op donderdag 03 mei 2007 @ 17:30:
Normaal gesproken heb je gelijk, maar in het geval van MySQL zou ik het niet doen.

Ze hebben nogal wat wijzigingen aangebracht in de werking van het native datum formaat van MySQL, dit maakt het upgraden van het database systeem erg lastig en vaak prijzig.

MySQL gaat aan de andere kant ook erg goed om met unix timestamps, net als PHP.

In de combinatie PHP/MySQL zou ik dus altijd aanraden de unix timestamps te gebruiken en niet het native formaat van MySQL.

Sorry dat ik het zeg, ik vind je message wel interessant genoeg om me daarin te verdiepen, heb je misschien ook enige onderbouwingen?

[Creepy]

Laatst was er ook al een discussie over DateTime vs timestamp als een int. Daarin heb ik in elk geval gemist dat er blijkbaar veranderingsn in de werking van het een DateTime formaat in MySQL zijn geweest die blijkbaar zo ernstig zijn dat je beter over kan stappen. Ik kan er eerlijk gezegd ook weinig over vinden. TRRoads: heb je iets meer info over welke wijzigingen dit zijn geweest?

[Verwijderd]

In de manual van MySQL is er genoeg over te vinden.

Er zijn twee aparte pagina's waarin het gedrag voor 4.1 en gedrag na 4.1 wordt beschreven.
Daarnaast zijn er bij versie 5 weer een aantal wijzigingen doorgevoerd (op zich geen ramp, versie 5 was toch al niet al te compatible). En daarna bij 5.1 ook weer.

Ook zijn er weer wijzigingen tussen 4.1 en 4.1.2.

Ook in de tussenliggende versies zijn er af en toe problemen geweest, dit gooien ze bij MySQL onder de noemer bugs, maar er is twijfel of dit werkelijk zo was.

Daarnaast hebben ze het gedrag bij bijvoorbeeld de ODBC koppeling een keer gewijzigd, iets wat ook een prijzig grapje is als je systeem daar vanaf hangt.

Voor versie 3.23 was de werking van het tijdsformaat weer anders, maar dat is al zo lang geleden dat dat nu eigenlijk niet echt relevant is.

Een van de grootste problemen met het MySQL formaat is dat de werking afhangt van de lokale tijdsinstellingen (nog steeds is dat een probleem hoewel nu ook UTC functies beschikbaar zijn vanaf 4.1.1, maar niet standaard gebruikt worden). Dat is natuurlijk iets wat je niet wilt hebben, het moet zoveel mogelijk onafhankelijk zijn.

Vooral omdat MySQL erg goed kan omgaan met de Unix timestamp is het dus vaak beter om over te stappen naar een Unix timestamp tov het native formaat. Ook in PHP is het erg makkelijk werken met een Unix timestamp, bij die combo is het dus helemaal aan te raden.

Voor 4.1.1 was er ook niet zoveel beschikbaar qua tijds functies in MySQL, zie ook: http://dev.mysql.com/doc/...e-and-time-functions.html
(en dan vooral de vele versie indicatoren bij de functies)

[ Voor 9% gewijzigd door Verwijderd op 03-05-2007 18:11 ]

[Creepy]

Ik ben zeker blind want redenen om een DateTime maar niet te gebruiken al dan niet in bepaalde versies van MySQL (of upgraden van een oude naar een nieuwe versie) kan ik niet vinden. Wel wat wijzigingen qua werking m.b.t. een TimeStamp maar dat is het dan ook.

Van zowel de 4.1 als de 5.1 manuals: For the DATETIME and DATE range descriptions, “supported” means that although earlier values might work, there is no guarantee.

The TIMESTAMP data type has varying properties, depending on the MySQL version. These properties are described later in this section.

Dus mijn vraag alweer: zijn er specifieke wijzigingen die jou hebben laten besluiten geen native MySQL date type te gebruiken?

[ Voor 9% gewijzigd door Creepy op 03-05-2007 19:51 ]

[Verwijderd]

Ze veranderen de werking van versie tot versie.

Oftewel als je een systeem maakt om te werken met een bepaalde versie en je gaat upgraden bijvoorbeeld voor een betere performance dan kost dat je een hoop centen doordat alles moet aangepast worden op die nieuwe versie. Het zijn ook geen kleine wijzigingen in de werking, het zijn behoorlijk ingrijpende wijzigingen.

Dit terwijl de rest van het geheel (tot versie 5) redelijk backwards compatible is gebleven.

Daarnaast de afhankelijkheid van lokale instellingen en tijdzones, dat is natuurlijk altijd een nadeel.

In mijn persoonlijke geval was het de wijziging in de ODBC connector die een klant van ons een bak centen heeft gekost doordat alles aangepast moest worden om goed te werken met de nieuwe connector. Daar was de klant niet happy mee en dus was ik er niet happy mee, vandaar dat ik nu liever kies voor de Unix timestamp die al een flinke tijd gelijk is gebleven.

Vooral ook omdat het voor MySQL weinig uitmaakt of je nu een Unix timestamp pakt of het interne formaat, hij werkt goed met beide.

Dus geen nadelen, een aantal voordelen = betere keuze lijkt me.

Alternatief is een wrapper om het hele tijd gebeuren heen (wellicht in een database connectivity layer), maar dat wordt minder vaak gedaan ook weer wegens bijkomende kosten van zoiets.

[ Voor 48% gewijzigd door Verwijderd op 03-05-2007 19:56 ]

[Creepy]

Hmja. Je zegt nu wel weer dat er iets veranderd van versie naar versie maar niet wat. Als het echt geen kleine wijzigingen zijn geweest dan lijkt het me dat er echt wel iets specifieks te noemen is. Ik kan het niet zo 123 vinden in de MySQL docs.

Je verhaal met de ODBC koppeling heeft ook niks te maken met het afraden van een bepaalde type. En de nadelen aan een unix timestamp in een integer opslaan is het niet meer kunnen gebruiken van MySQL functies met betrekking tot data en echte voordelen aan de unix timestamp in een int kan ik nog steeds niet ontdekken.

Ik zie software draaien op MySQL 3 en hoger (4.0 en 4.1) die voor alle datum zaken een Date gebruikt en voor het gros van de datum/tijd zaken een DateTime zonder problemen. Wat voor nadelen zitten hier nu dan aan en welke ellende ga ik krijgen met een overstap naar 5.x? Ik zie echt geen problemen.

[ Voor 21% gewijzigd door Creepy op 03-05-2007 20:12 ]

[Verwijderd]

Dit is de situatie voor 4.1
http://dev.mysql.com/doc/...en/timestamp-pre-4-1.html

Dit is de situatie vanaf 4.1
http://dev.mysql.com/doc/refman/4.1/en/timestamp-4-1.html

Wijzigingen genoeg toch? (Het feit alleen al dat ze daar twee hele pagina's aan wijden lijkt me genoeg te zeggen)

Daar in de manual staan nog veel meer wijzigingen opgenoemd.
Zie bijvoorbeeld http://dev.mysql.com/doc/...n/upgrading-from-4-0.html

Voordeel van een Unix timestamp is dat het altijd overal hetzelfde is en al jaren hetzelfde is.
Een Unix timestamp is een hele doeltreffende manier om een punt in de tijd te defineren door gewoon de afstand tot een ander punt in de tijd te noemen.

Hierdoor ben je onafhankelijk van tijdzones, wintertijd, zomertijd etc.
Maar je bent ook volledig onafhankelijk van een bepaalde kalender, je kunt een Unix timestamp gemakkelijk uitdrukken in iedere andere kalender, dat is dus een duidelijke scheiding van data en representatie van de data.

Doordat rekenen met timestamps erg eenvoudig is kan MySQL er ook goed mee rekenen, mocht je alsnog iets nodig hebben van de native functies dan is het met de UNIX_TIMESTAMP() en FROM_UNIXTIME() in no-time omgezet naar een native formaat.

In PHP wordt ook (voor PHP5) voornamelijk met Unix timestamps gewerkt, er is dan dus geen conversie nodig bij verwerking van de datum vanuit het native type in MySQL naar de timestamp. Doordat MySQL er ook goed mee overweg kan is ook daar geen conversie nodig.

En hoezo heeft het ODBC verhaal er niets mee te maken? Het is een voorbeeld van typisch gedrag van de MySQL organisatie wanneer het aankomt op het hele time/date verhaal. Namelijk van versie naar versie het gedrag omgooien wat gewoon geld kost. Het was dan ook de druppel die de emmer deed overlopen. Een timestamp is altijd al hetzelfde geweest en gaat ook echt niet veranderen.

Wat dus absoluut niet wil zeggen dat je geen goede software kunt maken met het native type van MySQL. Met een wrapper er omheen kom je amper problemen tegen bij het upgraden, je hoeft enkel de wrapper aan te passen. Maar het is natuurlijk wat eenvoudiger software te schrijven zonder voor ongeveer alles wat er is een wrapper te hoeven schrijven.

Maar als jij graag het native type gebruikt moet je dat helemaal zelf weten, wil niet zeggen dat het niet aan te raden is ivm compatibiliteit om gewoon de unix timestamps te gebruiken.

Na 4.1.2 lijken er overigens weinig zaken meer gewijzigd te zijn, dus voor een upgrade naar 5.x zou dat geen probleem moeten opleveren. Maar er zijn wel meer zaken die niet backwards compatible zijn bij versie 5 dus die overstap is sowieso geen simpele. (Als in alleen ff nieuwe MySQL installeren)

[ Voor 33% gewijzigd door Verwijderd op 03-05-2007 20:28 ]

[Creepy]

Wijzigingen ja maar voor zover ik het zie echt niks spannends waardoor je een flink deel van je software zou moeten omgooien omdat je van mysql 4.0 naar 4.1 zou gaan. Heb je echt geen specifiek iets wat je uren ombouwen in je code zou moeten kosten?

Het hele timezone, zomer/wintertijd e.d. is in een vorige topic ook al besproken (en laat mij in elk geval niet overstappen van een native type naar een timestamp in een int). Daarnaast wegen de voordelen van de datum functies die MySQL heeft vooro mij zwaarder dan dat PHP toevallig goed met een unix timestamp overweg kan. En natuurlijk is er meer dan PHP alleen

Problemen met compatibliteit ben ik nog niet tegengekomen in MySQL 3.23, 4.0 en 4.1.

Al met al zie ik geen reden om een native type af te raden.

[ Voor 10% gewijzigd door Creepy op 03-05-2007 20:32 ]

[Verwijderd]

In je software kun je bijvoorbeeld van de display width van het timestamp type gebruik hebben gemaakt, bij versie 4.1 hebben ze die hele functionaliteit laten vallen.

Daardoor moet je dus overal waar je daarvan gebruikt maakt dat wijzigen, in tabel definities, queries etc. Dat kan flink wat tijd kosten in een wat groter systeem.

Daarnaast heb ik al meerdere keren gezegd, vooral in de PHP/MySQL configuratie is het aan te raden. Het aanraden van een unix timestamp is natuurlijk niet hetzelfde als het afraden van het native type.

Ook heb ik al gezegd dat het prima mogelijk is het native type te gebruiken, het is dus echt een keuze.

Natuurlijk bestaat er meer dan PHP en MySQL, maar het overgrote deel is toch de bekende Apache MySQL PHP combo. Zo erg zelfs dat als ik op Google.nl lamp intyp (zonder hoofdletters oid) een groot deel van de eerste hits (en zelfs de eerste twee hits) gaan over deze combo ipv het ding aan het plafond.

En de featureset van MySQL icm datum/tijd voor 4.0 valt nogal tegen (zie de functielijst eerder gepost), dus te zeggen dat je er zoveel aan mist...

Nog een voorbeeldje:

Ben je klaar met versie 4.1, staat 4.1.1 om de hoek.
Ditmaal is de invoermogelijkheid van strings in datetime kolommen gewijzigd, dat allemaal weer wijzigen dus.

Dan dacht je dat je met versie 4.1.1 klaar was, maar daar staat 4.1.13 om de hoek.
Een minor versie dus een minor update zou je denken.

Helaas is nu het resultaat van DATETIME+0 gewijzigd, jongens ga maar weer aan de slag, er moet weer een hoop gewijzigd worden

(En zo kun je bezig blijven, zie de manual voor veel meer voorbeelden)

[ Voor 25% gewijzigd door Verwijderd op 03-05-2007 20:45 ]