automatisch databank bewerken zonder 'echte' trigger

Status
Niet open voor verdere reacties.
S

Sennec

Gebruiker
Lid geworden
17 jan 2009
Berichten
77
Hallo!

Ik heb een website waarop verslagen staan van bepaalde wedstrijden. Deze verslagen worden opgeslaan in een database en heeft een kolom "archief" die een waarde 1 of 0 kan bevatten. 1 wil zeggen dat het verslag oud is en in het archief kan geplaatst worden, dit archief is een andere pagina op mijn website waar alle verslagen ooit worden opgesomd behalve die van het huidige seizoen.

Ik hoop dat dit wat duidelijk geschetst is.

Dus wat ik graag zou willen is het volgende: als het seizoen gedaan is moeten deze verslagen nog even op de website blijven staan tot augustus. Eens augustus begint het nieuwe seizoen en moeten de oude verslagen een waarde van 1 krijgen bij "archief".

ik heb zelf wat zitten nadenken en kom bij het volgende:

als de maand van de huidige datum kleiner is dan 8 moet archief op 1 gezet worden
OF( als het jaar kleiner is dan het huidige jaar EN de maand van de huidige datum kleiner is dan 8.)

code hiervoor schrijven moeten lukken. Maar hoe laat ik dit AUTOMATISCH verlopen in de maand augustus ?
 
Het hoeft niet per se automatisch uitgevoerd te worden op de eerste minuut van augustus.

Je kunt gewoon bij elke aanvraag van de website (elke keer dat hij geopend wordt) controleren of de genoemde aanpassing gedaan moet worden. Met PHP kun je de tijd en datum opvragen. Mocht het huidige jaar niet in hij lijstje met reeds verwerkte jaren staan en als de datum verder in de kalender ligt dan 1 augustus, voert hij de wijziging uit. Vervolgens voegt hij ergens in een tabel in de database "2010" toe als jaar waarin hij deze aanpassing al heeft gemaakt. Als de eerste bezoeker pas op 15 augustus de website opent, blijft de oude waarde van archiefvinkjes tot die tijd in de database staan. Aangezien er geen andere mogelijkheid is voor gebruikers om de data in te zien, lijkt het net alsof deze aanpassing steeds in het begin van augustus is.

Daarnaast kun je wel php code uitvoeren op een bepaald tijdstip op bepaalde data, dit zijn de zogenaamde cron jobs. Dit is als een soort wekker voor een server. Je moet wel bij de zogenaamde crontab komen in de server om de code toe te voegen aan de lijst met cron jobs. Hiervoor heb je vaak meer rechten nodig op je webserver, dus als je deze webserver niet zelf beheert wordt dit een lastig te realiseren oplossing.

(heb mijn super lange zinnen even ingekort, excuses als je mijn hersenspinsels als eerder hebt proberen te ontcijferen)
 
Laatst bewerkt:
Je kunt ook een Cronjob instellen (hoe dat exact werkt is een beetje afhankelijk van je provider) die je bijv. op de eerste van elke maand een script aan laat roepen.
 
Ik snap het probleem niet.

De waarde archief 0 of 1 is niet relevant. Als je vanaf een bepaalt moment besluit om dat anders in te delen kun je weer overnieuw beginnen. Ik zou het véél simpeler doen:

1 VIEW aanmaken met het huidige seizoen en 1 VIEW voor 'de rest'. Wat 'de rest' is kun je later, indien nodig, herdefiniëren. De criteria voor wat dit seizoen is en wat niet heb je, dus daarmee kun je makkelijk aan de gang.
 
Wat SvU zegt is over het algemeen de betere oplossing, opzich.
 
Hier wil ik nog wel even op ingaan:

CUnknown zei:
Je kunt gewoon bij elke aanvraag van de website (elke keer dat hij geopend wordt) controleren of de genoemde aanpassing gedaan moet worden.
Klik om te vergroten...

Dit is dus exact de reden dat heel veel websites traag worden. Met jouw oplossing kun je net zo goed elke minuut een cronjob uit laten voeren. Of nog beter: het script permanent laten lopen.

Een beetje site handelt meerdere requests per seconde af, en met jouw methode ga je dus elke seconde een paar keer kijken of een seizoen naar het archief moet. Nu is dat misschien niet zo veeleisend in dit voorbeeld, maar als jij deze methodiek ook voor andere gevallen implementeert ga jij trage websites produceren die een onevenredig grote load hebben.
 
SvU zei:
Hier wil ik nog wel even op ingaan:



Dit is dus exact de reden dat heel veel websites traag worden. Met jouw oplossing kun je net zo goed elke minuut een cronjob uit laten voeren. Of nog beter: het script permanent laten lopen.

Een beetje site handelt meerdere requests per seconde af, en met jouw methode ga je dus elke seconde een paar keer kijken of een seizoen naar het archief moet. Nu is dat misschien niet zo veeleisend in dit voorbeeld, maar als jij deze methodiek ook voor andere gevallen implementeert ga jij trage websites produceren die een onevenredig grote load hebben.
Klik om te vergroten...

Excuus dat ik uit ben gegaan van een website die alleen door leden van een sportvereniging zelf wordt geraadpleegd.
Ik ging er inderdaad vanuit dat de websites gemiddeld 100 pageviews per maand had, dat was een beetje voorbarig van mij.

Ik ben het er zeker mee eens om een controle of een taak die maar een keer per jaar uit gevoerd moet worden niet 10000 keer per dag gedaan moet worden. Hoewel de check maar een query naar de database is, zorgt dit inderdaad voor overhead. Dat is ook een duidelijk voorbeeld van bad programmer practice. Ik wilde het echter niet te moeilijk maken. Ook ben ik er vanuit gegaan dat Sennec bij zijn webserver geen rootrechten heeft die je nodig hebt voor het toevoegen van een cronjob. Een cronjob is gewoon de beste manier. De cron daemon draait toch al altijd op een server, dus cron zorgt ook niet voor overhead, of je het nou gebruikt of niet.

Nu kan ik natuurlijk niet uit een kort verhaal precies opmaken wat de situatie is. vandaar dat ik een makkelijke (lelijke, vertragende) oplossing heb geschetst, en de oplossing zoals deze het meeste toegepast wordt.
Misschien had ik dat er bij moeten zetten.

En vergis je niet, een script permanent laten lopen door middel van een while(true) loop is 100x zwaarder voor een server dan uitvoer bij elke opvraag van een website. In dit geval zou hij het (mits de schedule algoritmes van het besturingssysteem niet ingrijpen) constant op de processor blijven draaien en zouden alle kloktikken gebruikt worden voor het uitvoeren van deze check.

Een view lijkt mij ook een mooie oplossing maar deze moet je dan per jaar zelf instellen (of wat voor een oplossing had je precies in gedachte?).
 
Laatst bewerkt:
Aan een VIEW hoef je bij vaststaande criteria niets meer aan te passen.

CREATE VIEW archief AS
SELECT
wedstrijd
WHERE
datum = eerder_dan_dit_seizoen

CREATE VIEW huidig_seizoen AS
SELECT
wedstrijd
WHERE
datum = dit_seizoen



Klaar.
 
ik was juist nieuwsgierig hoe je datum = huidig_seizoen uit de where clause wilde definiëren. Zonder dat je die 2e view niet elk jaar aan moet passen.
 
Een seizoen voldoet in beginsel aan bepaalde voorwaarden toch? Een seizoen begint in augustus en eindigt in mei. Alles van maand 7 of eerder in dit jaar (geldt tot en met december) en alles van maand 7 en eerder van vorig jaar (vanaf januari) is het vorige seizoen. Dat geldt altijd en is onafhankelijk van het jaar.
 
Kun je bij het definiëren van een VIEW dan een variabele gebruiken die aangeeft welk jaar het is bij het bekijken van de VIEW?
Ik dacht dat een view in principe altijd dezelfde constraints oplegde...
 
Je hebt SQL functies die het huidige jaartal en de huidige maand bijv. teruggeven; die kun je hier heel goed gebruiken :)
 
Je bedoelt zoiets als:

DATEPART(yyyy,CURDATE())

Maar wordt de uitkomst van de functie op het moment van het crieeren van de view niet in de definitie van de view verwerkt, in plaats van dat deze functie iedere keer als je de view bekijkt geëvalueerd wordt?
 
Een VIEW is een opgeslagen SELECT-query. De waardes veranderen dus wel.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan