Interface-Cron Logik

[Lokutos]

So mal wieder eine kleine frage meinerseits
die sich um keine funktion sondern nur aus logik zusammensetzt

Kurze erklärung
ich hab mir diverse crons angesehen und immer das selbe vorgehen

- erst alle kampagnen des ponsors und der werbeart auf status --> Inaktive
- alle kamagnen beim sponsor abfragen und auswerten
- jede einzelne kampagne select auf db ob kampagne (anhand sponsorname und kid) schon vorhanden ist und wenn ja upzudaten (alle werte und status auf aktive
- neue kampagnen speichern
- kampagnen auf status Inaktive am ende löschen

ich habe da mehrere fragen
einerseits passieren doch fehler wenn in einer anderen werbeart bei dem sponsor die kid schon vorhanden ist wird falsch upgedatet

$forcedbanner_check = db_query ("SELECT * FROM ".$db_prefix."_gebuchte_werbung WHERE sponsor = 'webmasterlose' and kid = '".$int_kid."'");
if (!mysql_num_rows($forcedbanner_check)) {
db_query ("INSERT INTO ".$db_prefix."_gebuchte_werbung (..........) VALUES ..............)");
} else {
db_query ("UPDATE ".$db_prefix."_gebuchte_werbung SET status = '1',........... WHERE sponsor = 'webmasterlose' and kid = '".$int_kid."' and status = '0'");
}


meine überlegung ist das man tans
so generieren könnte

$cron_wml_fb_d_tan = md5($cron_wml_fb['sponsor'].$cron_wml_fb_d_kid.$cron_wml_fb['werbeart']);
dan kann man am anfang einfach
delete where sponsor = and Werbeart =

und alles schnell neu einbuchen.


habe ich da einen denkfehler drinne oder etwas unangenehmes nicht bedacht.

mir geht es darum in meinem interface kann man alle sponsoren mit allen werbearten auf einmal aufrufen und da pro kampagne einen query nur zum scheuen obs die schon gibt finde ich bisschen viel (sind schnell mal 10000 querys)


Danke schon mal im vorraus

Lokutos

[Parl]

wenn in einer anderen werbeart bei dem sponsor die kid schon vorhanden ist wird falsch upgedatet

Dann müsste die Kampagne aber auch status = 0 haben. Es genügt doch eigentlich, zusätzlich die Werbeart mit einzubeziehen. (So wie es bei den STG Crons z.b. ist)


und alles schnell neu einbuchen.

Wenn man neu einbucht werden doch auch neue TAN's vergeben, was Auswirkungen auf aktuelle Reloads hätte.

Oder versteh ich da was falsch?

MFG

[didith1207]

genau... wenn man neu einbucht haben diese neue tans und die reloads stimmen nicht mehr also denkfehler ;)

[Lokutos]

bitte lesen danke.


meine überlegung ist das man tans
so generieren könnte

$cron_wml_fb_d_tan = md5($cron_wml_fb['sponsor'].$cron_wml_fb_d_kid.$cron_wml_fb['werbeart']);



so werden immer die selben tans generiert und gliefert werden auch optimale 32 zeichen

[D_Blade]

Ich denke man sollte es mal testen :think:

[didith1207]

bitte lesen danke.


meine überlegung ist das man tans
so generieren könnte

$cron_wml_fb_d_tan = md5($cron_wml_fb['sponsor'].$cron_wml_fb_d_kid.$cron_wml_fb['werbeart']);

so werden immer die selben tans generiert und gliefert werden auch optimale 32 zeichen



wie wäre es wenn du selber ließt?

auch wenn du den selben tan generieren würdest wäre der reload weg...
ausserdem könntest du deinen code ebenso gegen chinesische zeichen austauschen würde genauso sinnvoll sein wie deiner

[VMS1]

Na hier sind ja mal wieder die Experten am Werk.

@Lokutos:
- so wie du es im ersten Post machen willst, würde die Blacklist flöten gehen
- es macht keinen Sinn alle Werbearten/Sponsoren in ein Interface / Cron zu packen
- Tans per md5 zu generieren machen manche Leute schon seeeeehr lange^^
- es gibt mehrere Wege diese $forcedbanner_check-Abfrage zu umgehen. (z.B. kids per while-Schleife einlesen und Arrays vergleichen oder mysql_affected_rows benutzen oder beides).

@didith :
Erklär mal bitte, warum der Reload weg is, wenn die Kampagne mit derselben Tan wieder eingelesen wird?



Gruß
Marco

[Lokutos]

wie wäre es wenn du selber ließt?

auch wenn du den selben tan generieren würdest wäre der reload weg...
ausserdem könntest du deinen code ebenso gegen chinesische zeichen austauschen würde genauso sinnvoll sein wie deiner

Das erklär mal bitte
tans sind die selben reloads werden nicht in gebuchte_werbung gespeichert
insofern es so ist bitte erklären.




Na hier sind ja mal wieder die Experten am Werk.

@Lokutos:
- so wie du es im ersten Post machen willst, würde die Blacklist flöten gehen
- es macht keinen Sinn alle Werbearten/Sponsoren in ein Interface / Cron zu packen
- Tans per md5 zu generieren machen manche Leute schon seeeeehr lange^^
- es gibt mehrere Wege diese $forcedbanner_check-Abfrage zu umgehen. (z.B. kids per while-Schleife einlesen und Arrays vergleichen oder mysql_affected_rows benutzen oder beides).


Danke endlich mal ein Post mit sinn.

- so wie du es im ersten Post machen willst, würde die Blacklist flöten gehen
hm aber auch nur wenn die blackliste darauf basiert das man den status ändert und so eine kenne ich garnicht.

- es macht keinen Sinn alle Werbearten/Sponsoren in ein Interface / Cron zu packen
von sinn reden wir nicht aber die funktion ist da
biete an:
Sponsor xx alle werbearten mit einem aufruf
sponsor xx nur werbeart x in einem aufruf
alle sponsoren nur werbeart x in einem aufruf
alle sponsoren alle werbearten in einem auruf
aber was sinnvoll ist muss jeder selbst entscheiden


- Tans per md5 zu generieren machen manche Leute schon seeeeehr lange^^
möglich und ich auch *grins*


- es gibt mehrere Wege diese $forcedbanner_check-Abfrage zu umgehen. (z.B. kids per while-Schleife einlesen und Arrays vergleichen oder mysql_affected_rows benutzen oder beides).
werde ich mir mal ansehen.


MFG Lokutos

[Sebmaster]

- so wie du es im ersten Post machen willst, würde die Blacklist flöten gehen
hm aber auch nur wenn die blackliste darauf basiert das man den status ändert und so eine kenne ich garnicht.

Die Standard-VMS-Blcklist:eek::biggrin1:

Du dürftest halt nur die löschen, wo status != 2 ist.

[Lokutos]

Die Standard-VMS-Blcklist:eek::biggrin1:

Du dürftest halt nur die löschen, wo status != 2 ist.
ob das nun n zufall ist weis ich nicht aber die blackliste von interface funktioniert demfall auf dem selben system.