[PHP/MySQL] automatische querys/multi-threading

[Kapoen]

Ik ben nu bezig met het maken van een agenda systeem voor een
intranet website. Het is de bedoeling dat elk agenda punt een
vervaldatum meekrijgt. Eens deze datum voorbij moet dat agenda
punt netjes in het archief gedeponeerd worden en van de hoofdpagina
verwijderd. Vrij eenvoudige logica dus.

Wat is nu het probleem:
- PHP doet niets als je niets vraagt (logisch toch? )
- dus als ik vervallen agenda puntjes wil opsporen moet ik voor elke
user die binnenkomt een volledige lijst van agenda punten gaan
'query-en' op vervaldatums. Dit is eigelijk overbodig werk want het
is slechts 1x nodig.

Waar ik aan dacht als oplossing:
- een soort van achtergrond thread die op bepaalde tijdstippen
de gevraagde agenda punten filtert. In java zou dit dus een makkie zijn .

Is het mogelijk om in PHP een dergelijke thread te starten? Via de
GoT-search heb ik een cronjob oplossing gevonden, maar helaas draait de
webserver op een windows platform. En het is geen apache maar
IIS server. Buiten een phpMyAdmin interface met admin rights en een
mapje voor mijn webspace heb ik geen controle over de server.

Iemand een idee?

[cenix]

Ik heb zoiets nooit gedaan, maar het lijkt me dat PHP hiervoor (nog) niet zo geschikt is...
Ik kan je helaas ook niet aan een beter antwoord helpen...

[Stewie!]

taakplanner !? Elke dag effe progje aanroepen op php scriptje aanroepen
Makkelijk toch

[ Voor 14% gewijzigd door Stewie! op 10-03-2003 16:01 ]

[RobIII]

Je kunt je query toch schrijven als...

code:

Select bla bla bla from bla where vervaldatum>vandaag...

Of zie ik het dan verkeerd? Of moeten je records ook echt in een archief tabel worden gegooid?

[ Voor 21% gewijzigd door RobIII op 10-03-2003 16:05 ]

[wasigh]

Een pagina maken die dat updaten voor je doet.

optie 1: Dan een programmatje maken die elke dag die pagina oproept.
optie 2: Per dag bij de 1e bezoeker die op je site komt script aanroepen. Bijhouden of vandaag script al gedraaid heeft
optie 3: Linux Server zoeken, daar cronjob op draaiien die pagina aanroept.
optie 4: elke dag zelf een keer naar die pagina gaan
optie 5: alles uit de DB halen, maar de achterhaalde info niet weergeven

enzovoort

[Kapoen]

DaMorpheus schreef op 10 maart 2003 @ 16:00:
taakplanner !? Elke dag effe progje aanroepen op php scriptje aanroepen
Makkelijk toch

Zoals vermeld in mijn beginpost heb ik quasi geen toegangsrechten tot
de server waarop de website draait

Ik heb zoiets nooit gedaan, maar het lijkt me dat PHP hiervoor (nog) niet zo geschikt is...
Ik kan je helaas ook niet aan een beter antwoord helpen...

Dat is precies wat ik ook denk van PHP. Spijtig genoeg was dit het
enige alternatief om de site dynamisch te maken (in die zin dat de inhoud
ervan gewijzigd kan worden zonder kilometers html te moeten schrijven).

Of zie ik het dan verkeerd? Of moeten je records ook echt in een archief tabel worden gegooid?

Ja de records moeten effectief verwijderd worden uit de agenda tabel en naar
het archief verwezen worden.

optie 2: Per dag bij de 1e bezoeker die op je site komt script aanroepen. Bijhouden of vandaag script al gedraaid heeft
optie 3: Linux Server zoeken, daar cronjob op draaiien die pagina aanroept.

die optie 2 lijkt mij wel interessant, optie 3 zou ik natuurlijk het liefste zien,
maar voor een simpele stagair gaat dit bedrijf hun infrastructuur niet 'ff' overhoop
halen (eerst had ik nog niet eens de beschiking over PHP, maar verwachtten
ze van mij dat ik een nieuws/portal site in elkaar duw met alleen pure HTML
en JavaScript. Dus ze hebben al toegegeven ).

[ Voor 35% gewijzigd door Kapoen op 10-03-2003 16:14 ]

[RobIII]

Kapoen schreef op 10 March 2003 @ 16:07:
[...]
Nuja, dan zal ik maar een check moeten doen bij elke gebruiker.
Hopelijk levert dit niet teveel overhead op voor de MySQL server (een
p2 350).

Had je mijn post gezien? Is toch een kwestie van vervallen items eruit filteren met een where-clause of zo???

[ Voor 10% gewijzigd door RobIII op 10-03-2003 16:09 ]

[Kapoen]

RobIII sorry hoor, ik kan niet tegelijk postings lezen en zelf ook nog bezig zijn met reply-en

[RobIII]

Kapoen schreef op 10 March 2003 @ 16:13:
RobIII sorry hoor, ik kan niet tegelijk postings lezen en zelf ook nog bezig zijn met reply-en

Was ook niet als flame bedoeld, meer als vraagje.. Was bang dat je hem miste, en dat zou zonde zijn want mijn oplossing is denk ik zo slecht nog niet.

[dArtagnan]

Aanvulling op RobIII

Voorbeeld:
datum vandaag in een timesamp: 20030310161400
vervaldatum: 20030309000000
Voor hoofdpagina:
$query = "Select * from agenda where vervaldatum < datumvandaag";

Als de vervaldatum van het bericht groter is dan de datum van vandaag laat je het niet meer zie op de hoofdpagina, maar wel in het archief. En ook andersom.

[Kapoen]

Koraalduivel schreef op 10 March 2003 @ 16:17:
Aanvulling op RobIII

Voorbeeld:
datum vandaag in een timesamp: 20030310161400
vervaldatum: 20030309000000
Voor hoofdpagina:
$query = "Select * from agenda where vervaldatum < datumvandaag";

Als de vervaldatum van het bericht groter is dan de datum van vandaag laat je het niet meer zie op de hoofdpagina, maar wel in het archief. En ook andersom.

Dit zou kunnen werken, maar ik zit nog met een bedenking:
- Als je na verloop van tijd veel agenda punten hebt dan gaat MySQL toch
telkens weer dezelfde records voor niets nakijken? Als ik er van uit ga
dat de vervallen en actieve puntjes elkaar mooi opvolgen dan zit je na
een tijdje met een bovenste helft (of meer) van een tabel die volledig bestaat
uit vervallen punten en dus keer op keer voor niets nagekeken worden.

Of zie ik dit fout?

[RobIII]

Nee dat zie je m.i. goed, alleen denk ik niet dat je er veel van merkt tenzij het miljoenen records ofzo zijn... Het is m.i. de juiste oplossing voor dit soort problemen.

[Janoz]

RobIII schreef op 10 March 2003 @ 16:59:
Nee dat zie je m.i. goed, alleen denk ik niet dat je er veel van merkt tenzij het miljoenen records ofzo zijn... Het is m.i. de juiste oplossing voor dit soort problemen.

mwah.. het is eigenlijk meer verwaarloosbaar. Zeker als je een key op het datum veld zet zal de tijd logaritmisch toenemen. Dit betekend dat (nu ff uitgaande van ²log) het 1 extra vergelijking kost waneer het aantal records verdubbelen.

[djluc]

Als je verschillende tabellen voor het archief en de normale berichten moet je eerst eens gaan kijken of je helemaal begrijp hoe je dbmodellen moet maken, dan zul je tot de conclusie komen dat dat niet helemaal handig is.

[RobIII]

djluc schreef op 10 maart 2003 @ 17:10:
Als je verschillende tabellen voor het archief en de normale berichten moet je eerst eens gaan kijken of je helemaal begrijp hoe je dbmodellen moet maken, dan zul je tot de conclusie komen dat dat niet helemaal handig is.

Als je hier op doelt:

RobIII schreef op 10 maart 2003 @ 16:04:
[...]
Of zie ik het dan verkeerd? Of moeten je records ook echt in een archief tabel worden gegooid?

Mij zal het verder worst wezen hoe de TS het aan pakt, en ik post deze message dan ook alleen om je even te laten weten dat ik het he-le-maal met je eens ben

Maar als de TS een goede reden heeft om WEL een archief tabel te hebben (ik kan er dus geen bedenken) dan: wie zijn wij om 'm voor te schrijven wat wel en wat niet te doen? Ik vraag meestal niet verder bij dit soort dingen en probeer alleen een oplossing voor het probleem te vinden. De beweegredenen van een TS zijn in my opinion altijd onbelangrijk. Als een TS het zo wil, waarom niet?

* RobIII draaft door

[dArtagnan]

Kapoen schreef op 10 March 2003 @ 16:24:

Dit zou kunnen werken, maar ik zit nog met een bedenking:
- Als je na verloop van tijd veel agenda punten hebt dan gaat MySQL toch
telkens weer dezelfde records voor niets nakijken? Als ik er van uit ga
dat de vervallen en actieve puntjes elkaar mooi opvolgen dan zit je na
een tijdje met een bovenste helft (of meer) van een tabel die volledig bestaat
uit vervallen punten en dus keer op keer voor niets nagekeken worden.

Of zie ik dit fout?

Je kan ook eens per maand even alle records selecteren die vervallen zijn en ze vervolgens allemaal deleten.

[djc]

Koraalduivel schreef op 10 maart 2003 @ 17:32:
Je kan ook eens per maand even alle records selecteren die vervallen zijn en ze vervolgens allemaal deleten.

Of ze wegschrijven in HTML naar een archief bestandje met een leuk overzichtje van alle agendapunten in een maand?

En ze daarna alsnog verwijderen, uiteraard.

[ Voor 7% gewijzigd door djc op 10-03-2003 18:12 ]

[Kapoen]

De beweegredenen van een TS zijn in my opinion altijd onbelangrijk. Als een TS het zo wil, waarom niet?

als je het echt wil weten: ik probeer de hele boel zo performant mogelijk te maken . De reden dat ik de vervallen recordjes in een archief tabel wil:
dan kan ik gewoon een SELECT * FROM tabel loslaten op de tabel met de actieve punten zonder mij verder nog zorgen te moeten maken. Aangezien deze bewerking het meeste zal voorkomen wil ik ze zo kort mogelijk houden. Daardoor verhoogt het comfort van de bezoeker. Noem mij een muggezifter if you must
En dan is er nog het feit dat ik graag weet waar ik mee bezig ben en dan is
een beetje prutsen en experimenteren wel op zijn plaats .

Bedankt voor de tips allemaal

[martinvw]

De beweegredenen van een TS zijn in my opinion altijd onbelangrijk. Als een TS het zo wil, waarom niet?

Soms weet een TS ook niet helemaal wat hij wil en wist hij niet dat en vooral hoe het beter kan dus ik denk dat het over t algemeen geen kwaad kan door te vragen aan de TS

Dit is algemeen niet naar deze TS, eigenlijk ook ernstig offtopic.

ff ontopic dan

Een select met een extra voorwaarde is voor de database niet echt zwaar ofzo, maar jah het is natuurlijk je eigen keuze je weet nu wat er mogelijk is dus doe wat je het beste lijkt.

[Gomez12]

Als je gewoon een extra tabelletje aanmaakt met daarin alleen de waarde van vandaag, dan bij elke nieuwe sessie controleert of de waarde die in dat tabelletje staat die van vandaag is, als dat zo is doe dan niets, anders records opschonen. Dan schoont de eerste user van de dag de records op, is denk ik wel voldoende voor een intranetje

Of je gooit gewoon het opschoon script in een cronjob bij een client die er als eerste is

[ Voor 13% gewijzigd door Gomez12 op 10-03-2003 19:06 ]

[RobIII]

Kapoen schreef op 10 March 2003 @ 18:49:
[...]


als je het echt wil weten: ik probeer de hele boel zo performant mogelijk te maken . De reden dat ik de vervallen recordjes in een archief tabel wil:
dan kan ik gewoon een SELECT * FROM tabel loslaten op de tabel met de actieve punten zonder mij verder nog zorgen te moeten maken. Aangezien deze bewerking het meeste zal voorkomen wil ik ze zo kort mogelijk houden. Daardoor verhoogt het comfort van de bezoeker. Noem mij een muggezifter if you must
En dan is er nog het feit dat ik graag weet waar ik mee bezig ben en dan is
een beetje prutsen en experimenteren wel op zijn plaats .

Bedankt voor de tips allemaal

Muggezifter!!
Geintje...Ik beschouw mezelf eerder als bitnueker (dus ga met mij niet in discussie over dat soort zaken). Ik ben ook altijd bezig met alles nog sneller / beter en compacter te maken.

Maar soms moet je ook het performance gebeuren opzij zetten en juist kiezen voor de beste manier van aanpak. In dit geval ga ik dus nog steeds voor een extra where-clause. Met een index op de "vervallen" kolom is dat echt niet erg heavy ofzo. En wel zo makkelijk om straks wat "oude" items door te kijken ofzo. Tevens scheelt het gewoon in je ontwikkeltijd om dit soort rariteiten achterwege te laten. En geloof me, de gebruiker merkt het verschil van 0.001 seconde echt niet (en dan is het nog veel denk ik )

Tot slot, als we toch gaan bitnueken: Select * From ... is ook niet zo netjes. Gebruik liever Select koloma, kolomb, kolomc, ... From ...
Hoewel er al zat discussies over zijn ontstaan (ik verbied hier dan ook iedereen verder op in te gaan ) wil ik graag even verwijzen naar een quote uit dit artikel:

In SELECT statements, don't use SELECT * to return rows, always specify in your SELECT statement exactly which columns are needed to be returned for this particular query, and not a column more.

[Kapoen]

Select * From ... is ook niet zo netjes. Gebruik liever Select koloma, kolomb, kolomc, ... From ...

klopt, alleen weet ik voorhand nog niets af van de structuur van de gebruikte tabellen. Ik schrijf een soort van PHP 'klasse' (voor zover je over OO princiepes kan praten bij PHP) die eender wat voor tabel netjes kan afbeelden, zodanig dat ik niet voor elke pagina weer SQL moet coden .

Ik heb weer wat bijgeleerd met deze thread, bedankt allemaal!