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.
Ik heb zojuist een cronjob aangemaakt met de code van Arien en deze draait elk uur.
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.
>> Dat had ik kunnen doen ja, maar daarvoor is toch ook dit forum???
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.
Ik denk dat je een denkfout maakt als je zo graag die niet-afgeronde bestellingen weg wilt gooien.
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)?
?
Onbekende gebruiker
02-09-2022 15:48
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.
