Trigger instellen verstreken tijd in MySql
Ik sta even voor een uitdaging...
Ik heb in mijn database een Mandje waar een bestelling in komt te staan. Hier staat ook een TimeStamp veld in.
Nu weet ik dat ik met een trigger een timer kan activeren om deze input na een uur te verwijderen.
Ik heb dit geprobeerd maar ik kom er niet uit hoe ik dit moet instellen.
Het gaat er dus om dat hij NIET het gehele Mandje leeg gooit, maar alleen diegene die na een uur niet afgehandeld zijn.
Wie wil en kan me hierbij helpen?
Groet,
Nanno
Code (php)
1
2
3
2
3
DELETE
FROM cart_items
WHERE date_added < CURDATE() - INTERVAL 1 HOUR
FROM cart_items
WHERE date_added < CURDATE() - INTERVAL 1 HOUR
Gewijzigd op 01/09/2022 20:00:12 door - Ariën -
Wil je een zo leeg mogelijke database?
Of wil je de kans dat je iets verkoopt maximaliseren?
Ik heb ook wel eens van die momenten dat ik het alvast in mijn mandje gooi, en later op de dag ga betalen.
Zet het dan liever op een dag.
- Ariën - op 01/09/2022 19:59:55:
Met een query zoals dit:
Code (php)
1
2
3
2
3
DELETE
FROM cart_items
WHERE date_added < CURDATE() - INTERVAL 1 HOUR
FROM cart_items
WHERE date_added < CURDATE() - INTERVAL 1 HOUR
Is dit wat ik zo zou kunnen invoeren bij het aanmaken van de trigger in de MySql database?
Want dat stukje snap ik dus niet bij het aanmaken van de trigger.
Toevoeging op 01/09/2022 22:09:57:
- Ariën - op 01/09/2022 21:07:56:
Een uur vind ik wel erg over de top....
Ik heb ook wel eens van die momenten dat ik het alvast in mijn mandje gooi, en later op de dag ga betalen.
Zet het dan liever op een dag.
Ik heb ook wel eens van die momenten dat ik het alvast in mijn mandje gooi, en later op de dag ga betalen.
Zet het dan liever op een dag.
Er draait al een Cronjob die in de nacht alle bestellingen eruit gooit. Maar er zijn mensen die om 9:00 uur een bestelling toevoegen en daarna zie ik ze nooit meer op die dag. En bij het verkoop van kaartjes voor een voorstelling is het wel zo prettig dat deze dus eerder beschikbaar zijn op die dag.
Toevoeging op 01/09/2022 22:14:17:
Jan Koehoorn op 01/09/2022 20:03:52:
Normaal gesproken zou je hiervoor een cronjob kunnen gebruiken, maar MySQL kent ook scheduled events.
Die cronjob heb ik ook draaien maar die gooit in de nacht ALLE bestellingen eruit. Ik wil het graag instellen op een uur en begreep dat ik dit via de Trigger binnen MySql admin kan toevoegen. Maar ze vragen daar om een stukje code en ik begrijp niet wat ik daar moet plaatsen.
De link die je geeft heb ik doorgenomen, maar begrijp nog steeds niet goed hoe ik dit moet instellen en waar. Vandaar de vraag om hulp.
Toevoeging op 01/09/2022 22:18:48:
Ward van der Put op 01/09/2022 20:44:47:
Misschien moeten we het eerst eens over prioriteiten hebben.
Wil je een zo leeg mogelijke database?
Of wil je de kans dat je iets verkoopt maximaliseren?
Wil je een zo leeg mogelijke database?
Of wil je de kans dat je iets verkoopt maximaliseren?
Mensen plaatsen een bestelling voor kaartjes van een voorstelling maar handelen dit dan niet af.
Deze bestelling blijft dus de hele dag in het mandje staan totdat de cronjob het in die nacht er allemaal uit gooit.
Ik zou graag dat de database zelf elke bestelling automatisch na het verstrijken van het uur, die bestelling uit het mandje gooit. Bij het verkoop van kaartjes is dit wel erg wenselijk namelijk.
Ik begrijp alleen niet hoe en waar ik dit nu instel.
Cronjobje of realtime bij het laden van het script. Dat laatste heb ik destijds gedaan voor een lijst van actieve gebruikers op mijn site.
Ik zou zeggen dat de database verantwoordelijk is voor de integriteit van de data die daar is ogeslagen. De database bewaakt foreign key-relaties, andere checks en constraints. En wat mij betreft ook de bewaartermijnen.
Door de verantwoordelijkheid te leggen waar die hoort, is uitbreiding gemakkelijker te realiseren. Stel je wilt een extra clientprogramma voor gegevensbeheer of een andere rol in de organisatie, dan is het niet zo praktisch om de verantwoordelijkheid bij meerdere clientprogramma's te leggen.
Er kleven wel twee nadelen aan. Ten eerste moeten de ontwikkelaars meer weten van het SQL-protocol om de functionaliteit te kunnen gebruiken. (Maar ze hoeven niet zelf opnieuw het wiel uit te vinden.) Het tweede nadeel is dat je vast zit aan een bepaald merk database.
Zo ben ik ooit omgeschakeld van MySQL naar PostgreSQL. Dat traject heeft toen vier maanden in beslag genomen.
Bezint eer ge begint.
Overigens vind ik cronjobs geen ideale keuze. Dan introduceer je onnodig een derde entiteit, waar je vaak ook de hulp bij nodig hebt van de afdeling die het systeembeheer doet. Als je die extra schakel kan vermijden is dat een pré.
Ad Fundum op 02/09/2022 08:52:12:
Overigens vind ik cronjobs geen ideale keuze. Dan introduceer je onnodig een derde entiteit, waar je vaak ook de hulp bij nodig hebt van de afdeling die het systeembeheer doet. Als je die extra schakel kan vermijden is dat een pré.
"... is dat een pré."
Dat is geen pré. JIJ vindt dat een pré. Dat is prima, maar wel een persoonlijke opvatting.
Er is niks mis met een cronjob. Het argument dat je zou moeten overleggen met iemand van systeembeheer vind ik persoonlijk (mijn mening dus) een non-argument. Of je doet het zelf, of je vraagt een collega het te doen. Wat is daar erg aan? Dat je een "contactmomentje" met een ander individu hebt? Ik zie het probleem niet. Voordeel van een cronjob is dat je een algemeen aanvaarde query uit kunt voeren en dat er desgewenst ook code kan worden uitgevoerd.
Een cronjob laten draaien die elke 10 minuten van de dag even in het mandje kijkt lijkt me niet de beste optie.
Wel of geen trigger gebruiken? Andere opties?
Gewijzigd op 02/09/2022 12:51:47 door - Ariën -
Ik dacht dat een trigger een betere oplossing zou zijn, maar dit volstaat dus ook.
Bedankt in ieder geval voor de reacties en vooral Arien voor de oplossing.
- Ariën - op 02/09/2022 12:52:13:
Prima zo :-)
Even een vraagje, jij gebruikt CURDATE en ik gebruik al lange tijd NOW.
Wat is het verschil en wat is beter en waarom?
Hier een uitleg binnen 5 seconden gevonden:
https://www.tutorialspoint.com/What-is-the-difference-between-MySQL-NOW-and-CURDATE-function#
Gewijzigd op 02/09/2022 14:07:17 door Ozzie PHP
Ozzie PHP op 02/09/2022 14:06:50:
Dat zijn nou typisch vragen die je makkelijk even kunt Googlen.
Hier een uitleg binnen 5 seconden gevonden:
https://www.tutorialspoint.com/What-is-the-difference-between-MySQL-NOW-and-CURDATE-function#
Hier een uitleg binnen 5 seconden gevonden:
https://www.tutorialspoint.com/What-is-the-difference-between-MySQL-NOW-and-CURDATE-function#
Dat had ik kunnen doen ja, maar daarvoor is toch ook dit forum???
En nou zie ik dus dat CURDATE helemaal niet zou werken omdat ik de tijd wil controleren. En daar heb ik dus NOW voor nodig.
Dit forum is met name bedoeld voor als je ergens op vastloopt. Een beetje zelfredzaamheid wordt wel verwacht. Dus voordat je een vraag stelt, verwachten we wel dat je zelf al even op zoek bent gegaan naar een antwoord.
Voor vragen is er inderdaad dit forum, maar er wordt ook wel zelfredzaamheid hier verwacht, hoor ;-)
Je kunt prima controleren of een bestelling nog actueel is, door naar het tijdstip te kijken.
Active bestellingen: WHERE tijdstip > NOW() - INTERVAL 1 HOUR (of welke tijdsduur je wilt hebben)
Verlopen bestellingen: WHERE tijdstip < NOW() - INTERVAL 1 HOUR (of welke tijdsduur je wilt hebben)
Een bestelling van 61 minuten geleden duikt dan niet meer op in je lijstje. En een bestelling van 61 dagen geleden ook niet.
Zolang je databasetabellen niet in de miljoenen records lopen, zou ik die fijn laten staan.
Of ze eens per maand / week opruimen.
Je wilt namelijk misschien ooit eens weten hoeveel mensen dit gedrag vertonen. En dan daar de afdeling marketing op loslaten: "He Piet, je bestelling is nog niet afgerond. Vergeet je hem niet" of iets dergelijks.
Als blijkt dat deze verlaten mandjes maar 10x per week optreden, dan laat je het zo.
Zie je dat het heel veel voorkomt, dan ligt dat misschien aan je site (onduidelijkheid betalen, geen iDEAL etc).
Gooi jij om het uur alles ouder dan een uur weg, dan ben je heel je statistiek kwijt.
Dat jij mogelijk een uur een product gereserveerd houdt, is een ander punt, maar dat kun je met een simpele WHERE in je query ook oplossen ipv met tijdsgebonden query's.
Want wat als je job ineens stil ligt een dag. (bijvoorbeeld na een restart van Mysql)?
Ozzie PHP op 02/09/2022 12:13:51:
Dat is geen pré. JIJ vindt dat een pré. Dat is prima, maar wel een persoonlijke opvatting.
Ben jij dan van mening dat je hetzelfde beter door 3 afdelingen kan laten doen dan door 2 ?
Het wijkt volgens mij ook af van de SRP gedachte. De database is verantwoordelijk, PHP werkt er mee en dan betrek je ook nog de taakplanner van het besturingssysteem er bij. Ja, het natuurlijk makkelijk als je in je eentje de baas bent over een server, en misschien ook nog wel bij een kleinbedrijf waar je snel kan schakelen met mensen.
Mijn ervaring is in ieder geval dat die opzet echt niet handig is. Vooral wanneer die extra afdeling een aparte organisatie is. Dan gaat het van het budget af om ze die cronjobs te laten schrijven. De kans op fouten is dan ook groter, omdat ze geen domeinkennis hebben van de PHP applicatie (laat staan PHP). Je kunt niet snel even iets aanpassen, maar je bent afhankelijk van de capaciteit die beschikbaar is.
Jij spreekt uit eigen ervaring. Dat is geen enkel probleem. Vaak is het zo dat developers en systeembeheer op 1 afdeling zitten, of dat developers gewoon zelf cronjobs instellen.
En of iets bij 1 afdeling of 2 afdelingen ligt boeit me niet, mits je maar snel kunt schakelen.
Een aparte afdeling voor het schrijven van cronjobs heb ik nog niet eerder meegemaakt.
Anyhow. Jij ziet een hele hoop (mogelijke) problemen die ik persoonlijk niet zie. Wil niet zeggen dat ze in bepaalde bedrijven niet (kunnen) voorkomen, maar om daar een soort algemene stelregel van te maken en daarnaar te handelen gaat in mijn ogen wat ver. Maar goed, ieder z'n eigen opvatting uiteraard.