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.
Volgens mij is deze hele exercitie eigenlijk onnodig.
Laten we het eens omkeren: 100 personen hebben een ticket gekocht en dit fysiek op papier ontvangen.
Vanavond is een voorstelling om 20.00 en er komen 80 mensen opdagen.
Dat betekent dat er nog 20 tickets bij de mensen thuis zijn.
Wat nu? Ga je deze mensen opdracht geven om hun tickets te vernietigen? Ga je ze ophalen?
Nee toch? Op het ticket staat namelijk dat het geldig is voor voorstelling van X op datum 5 sept om 20.00. (en mogelijk laat je ze na 20.00 nog een half uur binnen komen)
Nu de analogie met je mandje:
In je mandje staat ook een geldigheidstijdstip. (of indirect: dat is de het tijdstip van in het mandje gooien + 1 uur).
Dan WEET je toch welke bestellingen er niet meer toe doen? en welke wel.
Het is dan alleen zaak om bij verschillende query's die jij kennelijk in je applicatie gebruikt niet "SELECT data FROM mandjes " te doen,
maar dat aan te passen naar
"SELECT data FROM mandjes WHERE besteltijd niet verlopen"
a) je zit niet te pielen met cronjobs of andere tijdsturingen
b) je historische data blijft staan. (bijvoorbeeld voor statistiek of voor "he klantenservice mijn bestelling komt niet binnen"
Ik wil je hierbij graag even uitleggen hoe het bestellen in een theater werkt. Dit staat geheel los van andere evenementen omdat we hier met een vaste aantal zitplaatsen zitten. In ons geval is het enkel reserveren van een stoel en niet daadwerkelijk een zitplaats kopen.
Het is net als winkelen in de supermarkt, je pakt je producten, kiest het aantal en legt dat in je winkelwagen of mandje.
Uiteindelijk bepaal je bij de kassa welke producten je werkelijk mee de winkel uit neemt.
Helaas moest ik constateren in ons systeem dat mensen een aantal tickets in het mandje plaatsen, maar op 1 of andere duistere reden er verder niks mee doen. Oftewel, er staat ergens in de winkel een mandje met brood omdat de klant zich bedacht heeft en de winkel uit is gelopen. Even terug leggen is er dus niet bij.
Nu dus het punt dat ik mijn winkel opgeruimd wil houden en dat soort verdwaalde producten weer in het schap wil leggen. Ik had hierbij niet nagedacht dat ik hier een cronjob voor kan gebruiken. Ik zag enkel de trigger als mogelijke oplossing.
Nu draait er een cronjob die elk uur even kijkt of er geen verdwaalde (niet afgehandelde bestellingen) producten in de winkel staan. En dit werkt inderdaad helemaal zoals ik het wil.
Het mandje staat namelijk geheel los van de afgehandelde bestellingen die langs de kassa zijn geweest. Die worden vastgelegd in een andere database item Bestellingen.
Ik hoop dat je nu mijn post en wens beter begrijpt.
Dit item kan dus als opgelost worden betiteld.
[size=xsmall]Toevoeging op 05/09/2022 17:44:45:[/size]
Ivo P op 05/09/2022 09:28:48
Wat nu? Ga je deze mensen opdracht geven om hun tickets te vernietigen? Ga je ze ophalen?
Nee toch? Op het ticket staat namelijk dat het geldig is voor voorstelling van X op datum 5 sept om 20.00. (en mogelijk laat je ze na 20.00 nog een half uur binnen komen)
De bezoekers krijgen 5 dagen voor de desbetreffende voorstelling een herinnering per e-mail. Dit is ook een cronjob die elke week draait en alle klanten uit de database filtert. Ik krijg hier dus met regelmaat een wijziging of annulering op terug.
Dit werkt perfect want we hebben nagenoeg geen lege stoelen bij een uitverkochte voorstelling.
En nee, in een theater kom je de zaal niet meer binnen na aanvang.
[size=xsmall]Toevoeging op 05/09/2022 17:49:38:[/size]
Ivo P op 05/09/2022 09:28:48
Dan WEET je toch welke bestellingen er niet meer toe doen? en welke wel.
Het is dan alleen zaak om bij verschillende query's die jij kennelijk in je applicatie gebruikt niet "SELECT data FROM mandjes " te doen,
maar dat aan te passen naar
"SELECT data FROM mandjes WHERE besteltijd niet verlopen"
a) je zit niet te pielen met cronjobs of andere tijdsturingen
b) je historische data blijft staan. (bijvoorbeeld voor statistiek of voor "he klantenservice mijn bestelling komt niet binnen"
Dat is nou juist het issue, waar en hoe laat ik het script even controleren op verdwaalde niet afgehandelde bestelling na het uur van in het mandje plaatsen?
Ik begrijp niet wat je hier nou mee wil zeggen, want wie en wat activeert dan mijn script?
Dus punt A is juist mijn oplossing maar jij ziet iets anders wat ik niet zie.
Als ik zo begrijp maak je direct op het eerste punt van bestellen een ticket aan, met een verloopdatum. Zodra er betaald is binnen die verloopdatum is deze omgezet in een definitief ticket. Een verlopen ticket tel je niet mee in de verkoop, maar blijft wel bij voorkeur bestaan voor statistieken. Op deze manier heb je geen cronjobs nodig, en kan je in je applicatie tellen hoeveel er tickets er betaald zijn, en bij het overschrijden ervan is het een "Helaas" voor de klant. Je kan dan nog automatisch refreshen met de hoop dat er een ticket verloopt, zodat er nog hoop is voor diegene is.
Hmmm ... begrijp ik nu goed dat de situatie momenteel zo is dat als iemand een ticket in z'n winkelmandje stopt en die nog niet heeft afgerekend, dat ticket geldt als een reservering?
Daar komt het wel op neer. Als je te lang bij de kassa staat te twijfelen zal de kassière ook wel zeggen dat die ze dan liever aan iemand anders verkoopt.
precies:
als je 200 stoelen te verkopen hebt, dan kan er dus 200x een ticket in een bestelling geplaatst worden en betaald worden.
gedurende een uur na "in het mandje leggen" geef je de tickets een soort van tijdelijke status "verkocht".
Dat zijn dus de tickets die minder dan een uur in je mandje liggen.
Dus rekenvoorbeeld:
vanmorgen ging iets in de verkoop met 200 stoelen voor as. vrijdag.
om 17.00 gooit iemand 10 tickets in de reservering en doet er niets mee (betaalt niet)
om 18.00 gooit iemand 5 ticket in zijn mandje en betaalt ook nog niet.
Het is nu 18.05
Er zijn nu dus 195 tickets beschikbaar: 200 oorspronkelijk en er liggen er 5 minder dan een uur in het mandje.
Daar is geen cronjob voor nodig toch?
Je zou er zelfs voor kunnen kiezen dat als persoon 1 vanavond om 20.00 nog besluit om toch te betalen en er zijn nog steeds 10 stoelen beschikbaar, dan kan hij ze alsnog krijgen.
Ik weet niet of je op stoelnummer werkt, maar ook dan gaat het nog op:
een "mandje "( noem ik het maar even) is alleen geldig als de timestamp minder dan 1 uur in het verleden ligt.
En van opruimacties heb ik in het verleden vaak genoeg spijt gehad.
Of het nu om historische data van 5 jaar terug ging of om log-files van Apache.
Vaak genoeg staat dat een jaar te slapen en 3 dagen na het wissen komt iemand met de vraag om daar eens een gemiddelde over te berekenen.
En: cronjobs en dergelijke draaien een beetje buiten het zicht. Als die stilvallen, dan kom je daar mogelijk pas achter als je zaal bijna leeg is, omdat de reserveringen niet opgeruimd werden.
Query je beschikbaarheid op basis van "niet meer dan 1 uur oud" dan heb je daar geen probleem mee.
(en je kunt nog steeds eens per maand opschonen als je de kriebels van slapende data krijgt.)
Of na die maand je data aggregeren. Nog compacter.
Maar omdat je een stoel reserveert, hoe voorkom je dan dat iemand je hele kaartverkoop platlegt door met 100 man, of een gecreëerd botnet) constant winkelwagentjes staat te vullen met tickets? Niemand die dan door de kaartverkoop komt omdat al die tickets dan gereserveerd zijn.
Misschien een wachtrij maken? En een mail sturen zodra er een ticket beschikbaar is?
Ook daar moet je dan weer slimmigheidjes bedenken en drempels voor werpen.
Dat zet mij wel op het idee waarom je vaak bij ticketverkopen vaak een wachtrij-indicator ziet (vaak een externe partij) voordat je een ticket gaat kopen. Ik kan me nog een nieuwsbericht herinneren met dat er 300.000 mensen in de virtuele wachtrij stonden.
Er zijn 200 tickets voor een voorstelling beschikbaar.
Wanneer is een ticket niet meer beschikbaar? Enkel en alleen als deze is betaald.
Het feit dat iemand iets in z'n winkelmandje legt, moet je niet gaan beschouwen als een reservering.
Als iemand een ticket in z'n mandje gooit en hij gaat betalen, dan check je op dat moment de beschikbaarheid. In mijn optiek kan het niet zo zijn dat door iets in je winkelmandje te plaatsen (en verder niks) je daarmee een ticket reserveert. Daar zal een betaling aan vast moeten zitten.
Als ik op de website van MediaMarkt een televisie in m'n winkelmandje gooi dan heb ik die ook niet ineens gereserveerd. Als er nog maar 1 exemplaar is, en iemand anders betaalt de televisie eerder dan ik, dan heb ik gewoon pech.
Er zijn 200 tickets voor een voorstelling beschikbaar.
Wanneer is een ticket niet meer beschikbaar? Enkel en alleen als deze is betaald.
Het feit dat iemand iets in z'n winkelmandje legt, moet je niet gaan beschouwen als een reservering.
Zeker weten? Als ik bij het Schouwburg een ticket bestel en een stoel kies, dan wordt dit voor mij gereserveerd voor 20 minuten. Ik ben dus zeker van dat als ik betaald heb binnen de 20 minuten, dat deze voor mij is. Als het de laatste stoel is, dan zal iemand helaas een volgeboekte zaal zien. Als ik toch niet betaald heb, en de tijd is verlopen, dan is hij weer vrij voor iemand anders.
Als ik op de website van MediaMarkt een televisie in m'n winkelmandje gooi dan heb ik die ook niet ineens gereserveerd. Als er nog maar 1 exemplaar is, en iemand anders betaalt de televisie eerder dan ik, dan heb ik gewoon pech.
En volgens mij is dat ook bij vele webwinkels zo. Ik had pas geleden het laatste product bij een webwinkel, en voordat ik deze betaald had, ging ik uit interesse kijken in de incognito-modus en daar was hij verkocht. Het ligt er naar mijn idee net aan hoe de logica gebouwd is.
Als ik op de website van MediaMarkt een televisie in m'n winkelmandje gooi dan heb ik die ook niet ineens gereserveerd. Als er nog maar 1 exemplaar is, en iemand anders betaalt de televisie eerder dan ik, dan heb ik gewoon pech.
Hier zit nou JUIST de functie van dat mandje!!
Zodra er iemand een aantal kaarten besteld, en dat zijn de laatste, dan zal mijn systeem de voorraad op nul zetten en dus de melding UITVERKOCHT weergeven.
Als ik dus niets onderneem om die kaarten na een uur niet te zijn afgehandeld, dan blijft het op uitverkocht staan totdat...???
Aangezien ik dus niets heb ingesteld in MyPHPAdmin als zijnde doe iets met die kaarten na een bepaalde tijd, waarvan ik dus ook niet weet hoe ik dit zou moeten instellen zonder een trigger of cronjob, blijven deze kaarten oneindig in het mandje staan.
Nu met de cronjob geeft hij elk uur de niet afgehandelde kaarten weer vrij. En ik kan zelf ook in het systeem kijken en actie ondernemen.
En wij werken per seizoen. De database blijft 1 jaar bestaan en daarna wordt deze verwijdert.
Ik maak dus voor elk seizoen een nieuwe database aan.
[size=xsmall]Toevoeging op 05/09/2022 19:27:47:[/size]
- Ariën - op 05/09/2022 19:06:29
Zeker weten? Als ik bij het Schouwburg een ticket bestel en een stoel kies, dan wordt dit voor mij gereserveerd voor 20 minuten. Ik ben dus zeker van dat als ik betaald heb binnen de 20 minuten, dat deze voor mij is. Als het de laatste stoel is, dan zal iemand helaas een volgeboekte zaal zien. Als ik toch niet betaald heb, en de tijd is verlopen, dan is hij weer vrij voor iemand anders.
Juist!, hier zat dus mijn uitdaging van die 20 minuten, hoe regel ik dit en hoe handel ik dit met een script af? Dat was dus mijn idee van een trigger of een cronjob.
Als je een andere manier zou weten die beter zou zijn, dan verneem ik dat graag hoe jij dat zou oplossen.
