Trigger instellen verstreken tijd in MySql

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 3 volgende »

Nanno Koerts

Nanno Koerts

01/09/2022 17:42:14
Quote Anchor link
Beste mensen,

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
 
PHP hulp

PHP hulp

01/02/2023 11:24:14
 
- Ariën  -
Beheerder

- Ariën -

01/09/2022 19:59:55
Quote Anchor link
Met een query zoals dit:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
DELETE
FROM cart_items
WHERE date_added < CURDATE() - INTERVAL 1 HOUR
Gewijzigd op 01/09/2022 20:00:12 door - Ariën -
 
Jan Koehoorn

Jan Koehoorn

01/09/2022 20:03:52
Quote Anchor link
Normaal gesproken zou je hiervoor een cronjob kunnen gebruiken, maar MySQL kent ook scheduled events.
 
Ward van der Put
Moderator

Ward van der Put

01/09/2022 20:44:47
Quote Anchor link
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?
 
- Ariën  -
Beheerder

- Ariën -

01/09/2022 21:07:56
Quote Anchor link
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.
 
Nanno Koerts

Nanno Koerts

01/09/2022 22:07:28
Quote Anchor link
- Ariën - op 01/09/2022 19:59:55:
Met een query zoals dit:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
DELETE
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.


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?


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.
 
- Ariën  -
Beheerder

- Ariën -

01/09/2022 23:13:35
Quote Anchor link
ik heb nooit met die trigger gespeeld, maar zelf vind ik dit meer iets wat je in PHP kan uitvoeren.
Cronjobje of realtime bij het laden van het script. Dat laatste heb ik destijds gedaan voor een lijst van actieve gebruikers op mijn site.
 
Ad Fundum

Ad Fundum

02/09/2022 08:52:12
Quote Anchor link
Het hangt er van af 'wie' er verantwoordelijk is voor de datakwaliteit. Is dat PHP, of MySQL, of allebei?

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é.
Gewijzigd op 02/09/2022 09:00:38 door Ad Fundum
 
Ozzie PHP

Ozzie PHP

02/09/2022 12:13:51
Quote Anchor link
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.
 
Nanno Koerts

Nanno Koerts

02/09/2022 12:22:05
Quote Anchor link
Is er dan iemand op dit forum die me gewoon even kan vertellen en laten zien wat ik dan wel het beste kan doen zonder dat we hier een onnodige discussie krijgen?

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?
 
- Ariën  -
Beheerder

- Ariën -

02/09/2022 12:51:24
Quote Anchor link
Of gewoon realtime bij het uitvoeren van het script. Maar als het een drukke site is, moet je spaarzaam zijn met query's. Dan zijn cronjobs de beste oplossing.
Gewijzigd op 02/09/2022 12:51:47 door - Ariën -
 
Nanno Koerts

Nanno Koerts

02/09/2022 12:51:39
Quote Anchor link
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.
 
- Ariën  -
Beheerder

- Ariën -

02/09/2022 12:52:13
Quote Anchor link
Prima zo :-)
 
Nanno Koerts

Nanno Koerts

02/09/2022 12:54:16
Quote Anchor link
- 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?
 
Ozzie PHP

Ozzie PHP

02/09/2022 14:06:50
Quote Anchor link
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#
Gewijzigd op 02/09/2022 14:07:17 door Ozzie PHP
 
Nanno Koerts

Nanno Koerts

02/09/2022 14:10:41
Quote Anchor link
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#


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.
 
Ozzie PHP

Ozzie PHP

02/09/2022 14:15:02
Quote Anchor link
>> 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.
 
- Ariën  -
Beheerder

- Ariën -

02/09/2022 14:16:17
Quote Anchor link
Dan moet je NOW() gebruiken.

Voor vragen is er inderdaad dit forum, maar er wordt ook wel zelfredzaamheid hier verwacht, hoor ;-)
 
Ivo P

Ivo P

02/09/2022 15:21:30
Quote Anchor link
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)?
 
Ad Fundum

Ad Fundum

02/09/2022 15:48:15
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

02/09/2022 16:22:09
Quote Anchor link
@Ad Fundum

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.
 

Pagina: 1 2 3 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.