1x per dag

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: « vorige 1 2 3 volgende »

Ozzie PHP

Ozzie PHP

24/11/2011 15:47:07
Quote Anchor link
* BUMP *

Kan iemand het mij uitleggen? Wat is het voordeel om te controleren of iemand de 1e bezoeker is ten opzichte van het controleren van een datum? Ik zie blijkbaar iets over het hoofd, maar ik heb geen idee wat.
 
PHP hulp

PHP hulp

25/04/2024 16:11:08
 
Jelle -

Jelle -

24/11/2011 16:32:31
Quote Anchor link
Als je een log bij houdt van je bezoeker data heb je daar vaak ook een datum bij, dan kun je toch het aantal rijen data bepalen voor een bepaalde dag en als dat groter is dan 1, dan betekend dat je niet de eerste bezoeker bent :)

Maar je zou het ook gewoon met iets van een setting veld doen ergens (ik neem aan dat je een aantal settings hebt) en daarmee kijken of het al weer 24 uur geleden is of iets dergelijks.

Tis gewoon een keuze die je maakt :)
 
Ozzie PHP

Ozzie PHP

24/11/2011 16:57:38
Quote Anchor link
Dankjewel voor je reactie Smurf.

Maar stel dat ik bij iedere pagina-aanroep zou controleren:

if ($aantal_bezoekers_met_datum_van_vandaag > 0) {
// ga cache leeggooien
}

wat is dan het voordeel ten opzichte van

if ($datum_vandaag > $datum_laatste_keer_gecachet) {
// ga cache leeggooien
}

Volgens PHP Knipper is er een bepaald voordeel van manier 1, maar ik heb geen flauw idee wat hij bedoelt??
 
Ozzie PHP

Ozzie PHP

06/12/2011 09:44:42
Quote Anchor link
* bump *
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

06/12/2011 10:19:06
Quote Anchor link
Allereerst zou ik niet een willekeurige bezoeker 'lastig vallen' met het onderhoud van de site, maar dit in het admin gedeelte doen.
Ik denk dat Knipper bedoeld dat als je een tabel hebt die geupdated wordt zodra je een bezoeker op de site je daar de datum uit kan halen, dan hoef je er geen apparte tabel voor aan te maken.
 
Ozzie PHP

Ozzie PHP

06/12/2011 10:36:26
Quote Anchor link
Ger, allereerst bedankt dat je even de moeite neemt om mijn vraag te beantwoorden.

Wat bedoel je precies met het "lastig vallen" van een bezoeker? Als het goed is merkt de bezoeker er toch helemaal niks van (aangezien het proces op de achtergrond wordt uitgevoerd)? De bezoeker is uitsluitend een "trigger".

"Ik denk dat Knipper bedoeld dat als je een tabel hebt die geupdated wordt zodra je een bezoeker op de site je daar de datum uit kan halen, dan hoef je er geen apparte tabel voor aan te maken."

Euh.. ik snap niet wat je bedoelt. Ik probeer nog even uit te leggen wat mijn idee was: bezoeker komt op site. Ik check (1x per sessie) of de datum gelijk is met de "laatste keer opgeschoond" datum in de database. Ja, dan niks doen. Nee, dan (op de achtergrond) opschoon actie uitvoeren en de datum "laatste keer opgeschoond" in de database wijzigen naar de huidige datum. Dat is hoe ik het bedacht had. Die manier van users in de database opslaan is me echter nog steeds niet duidelijk. Kun je een (kort) voorbeeldje geven?
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

06/12/2011 12:04:26
Quote Anchor link
Wat ik bedoel is het volgende:
Stel dat je in de database een tabel hebt waarin je site visits bijhoudt, dan zou je die kunnen gebruiken om de datum te checken. Als je zo'n tabel niet hebt, moet je natuurlijk niet één aanmaken alleen maar voor dat doel en kan je het beter doen zoals je het nu doet.

Op de achtergrond is betrekkelijk, de gebruiker ziet niet wat er gebeurd maar zou wel iets kunnen merken. Maar als het alleen cache legen is zal dat nihil zijn.
Gewijzigd op 06/12/2011 12:05:21 door Ger van Steenderen
 
Ozzie PHP

Ozzie PHP

06/12/2011 12:33:42
Quote Anchor link
Oké, dankjewel voor de uitleg. Ik snap wat je bedoelt met zo'n tabel (die ik niet heb overigens), maar ik snap nog steeds niet op welke manier dit sneller zou zijn. Je moet dan toch nog steeds de datums vergelijken?
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

06/12/2011 12:48:03
Quote Anchor link
Het is ook niet sneller (of langzamer) je hoeft alleen geen extra tabel aan te maken.
Overigens heb ik een soort gelijk iets maar ik houd het bij in een logfile en check op de bestandsdatum
 
Ozzie PHP

Ozzie PHP

06/12/2011 13:19:34
Quote Anchor link
Hmmm, ja... maar het is maar 1 extra tabelveldje, want die kan ik vast wel bij een andere tabel stoppen met website informatie.
 
Ozzie PHP

Ozzie PHP

11/12/2011 11:51:38
Quote Anchor link
Even een andere vraag...

Ik weet dat er webshops zijn die 1x per dag (bijv. 's nachts) alle prijzen van hun artikelen bijwerken aan de hand van de actuele gegevens van de leverancier. Het kan dan gaan om honderduizenden producten. Iedere nacht draait er dan een paar uur een cronjob die alle prijzen update. Wat vinden jullie daar eigenlijk van? Is dit een goede manier? Je zou er namelijk ook voor kunnen kiezen om de prijs te updaten zodra de pagina de 1e keer op die dag wordt opgevraagd. Vervolgens sla je de prijs op in de database. Als iemand anders diezelfde dag de prijs opvraagt, dan toon je de prijs uit de database. Wat is volgens jullie beter / logischer?
 
Ozzie PHP

Ozzie PHP

12/12/2011 16:51:15
Quote Anchor link
* bump *
 
Niels K

Niels K

12/12/2011 18:24:11
Quote Anchor link
Middels crons.
 
Ozzie PHP

Ozzie PHP

12/12/2011 20:04:09
Quote Anchor link
@Niels... kun je een toelichting geven waarom dat via crons beter is dan te updaten op het moment dat je het nodig hebt?
 
Noppes Homeland

Noppes Homeland

12/12/2011 20:45:04
Quote Anchor link
Gezien het feit je dit niet wil laten lopen via het webserver proces. En het is een proces wat je niet aan een eventuele voorbijgangen overlaat.

Quote:
Iedere nacht draait er dan een paar uur een cronjob die alle prijzen update.

Nee, het zal op z'n hoogst 2 a 3 seconden duren om de prijzen toe te voegen dan wel te updaten, ligt er maar net aan hoe slim jij het opzet.
 
Ozzie PHP

Ozzie PHP

12/12/2011 20:49:06
Quote Anchor link
Ik ken een situatie waarin 100.000 prijzen geupdate moeten worden. Dit duurt een paar uur :-s

Kun je me nog even uitleggen waarom je dit niet via het webrpoces zou willen laten lopen? Wat is precies het nadeel daarvan?
 
Aad B

Aad B

12/12/2011 21:08:01
Quote Anchor link
100k records updaten kan wel in enkele minuten met slimme SQL. Helaas halen php programmeurs nogal vaak hele bakken met data cq complete tabellen over naar php om die in loopjes te processen. Overigens is de crontab het juiste mechanisme om unattended periodieke taken af te handelen en niet de sessie van de 1e gebruiker die inlogt om 00:01 uur.
 
Ozzie PHP

Ozzie PHP

12/12/2011 21:15:40
Quote Anchor link
"Overigens is de crontab het juiste mechanisme om unattended periodieke taken af te handelen en niet de sessie van de 1e gebruiker die inlogt om 00:01 uur."

Wat versta je onder unattended periodieke taken... en WAAROM niet via 1e gebruiker die inlogt? Het gaat mij vooral om het WAAROM.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

12/12/2011 21:34:51
Quote Anchor link
Ozzie het is heel eenvoudig:
Je laat een willekeurige gebruiker een proces uitvoeren waarover je niet de absolute controle hebt. Wat gebeurt er als bv de db server van de leverancier offline is, dan krijgt de gebruiker niet te zien wat hij/zij verwacht.
Daarnaast maak je een verbinding met een externe server, dat kost je min. een paar seconden, vinden gebruikers niet leuk.
@Aad, als ik met het ophalen van bakken data een aantal queries kan voorkomen, dan geniet dat mijn voorkeur.
Gewijzigd op 12/12/2011 21:52:47 door Ger van Steenderen
 
Ozzie PHP

Ozzie PHP

12/12/2011 21:37:27
Quote Anchor link
En wat nu als het om processen gaat waar je WEL controle over hebt? Bijvoorbeeld het vernieuwen van gecachte bestanden?
 

Pagina: « vorige 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.