> Tja, ich hatte auf die Frage zu einer prozentualen Verteilung von > Bannern geantwortet. Dein "Problem" mit Bannerauftr�gen sollte damit > nicht beantwortet werden. Deshalb verstehe ich Deine Kritik nicht und > deshalb wirkt die Kritik auf mich auch nicht sehr angenehm, sorry!
War nicht b�s' gemeint... > > In meinem Beispiel wird von Deinem System die neu gebuchten Bannern > f�r > > eine ganze Weile auf 100% geschraubt... Also nichts mit prozentualer > > richtiger Verteilung... > > ... weil Du wahrscheinlich beim Einf�gen des neuen Banners nicht alle > Z�hler auf 0 gesetzt hast, was bei einer prozentualen Verteilung halt > erforderlich ist, wenn die Verteilung nach dem Hinzuf�gen von Bannern > neu gelten soll, ohne die Vergangenheit zu ber�cksichtigen. Mag sein... Das ist bloss nicht sehr praxistauglich... Oder sehe ich da was falsch? > > > Und was meinst Du mit "Zeit ber�cksichtigen"? Dein System > ber�cksichtigt > > jedenfalls nichts dergleichen und ist so wie vorgestellt nicht > > verwendbar. > > Sorry, wenn ich nicht gleich alles aufgeschrieben habe, aber in der > Frage ging es doch um prozentuale Verteilung, oder? > > Wenn man dagegen Bannerauftr�ge abarbeiten will, muss die > Bedarfsfunktion noch stark erweitert werden. So kann man > beispielsweise > Platzierungsvorgaben und Zeitvorgaben einflie�en lassen. Statt des > Quotienten kann man genauso gut die Differenz zwischen gew�nschten und > erledigten Bannern nehmen und durch die Restzeit dividieren. Bei > Platzierungsvorgaben kann man Banner, die auf bestimmten Seiten > platziert werden sollen, entsprechend st�rker gewichten. > > Das alles �ndert nichts an dem Grundprinzip: �ber eine Funktion > eindeutig zu bestimmen, welche Banner als n�chstes dran sind, Sorry, aber so eine allgemeine Aussage tr�gt f�r mich nicht zur L�sung des Problems bei... Immerhin geht es hier darum so ein System zu implementieren... Solche Aussagen funktionieren immer... z.B. "Workflows-Schritte lassen sich abarbeiten, indem man eine Funktion implementiert, welche eindeutig bestimmt, welcher Step als n�chster dran ist..." :-\ Oder: "Problem X l�sst sich l�sen, indem man eine Funktion schreibt, die das Problem l�st"... > eingeblendet zu werden. Das Problem vieler Bannerrotatoren > ist n�mlich, > dass die gleiche Banner einem Benutzer mitunter viel zu h�ufig gezeigt > werden. Ziel der Werbetreibenden ist in der Regel, die Banner weit zu > streuen. Und was genau an Deinem Ansatz verhindert das? Ansonsten, nicht b�se sein... Ich habe nichts gegen Dich, falls Du das meinst... Wir diskutieren hier nur ein Thema und da muss man schon mal Kritik ab k�nnen ohne gleich einzuschnappen (womit ich Dir nicht unterstellen m�chte, dass Du eingeschnappt bist.. ;-))... ...Aber wenn Dir das Thema inzwischen nicht mehr diskussionsw�rdig erscheint, ist das f�r mich auch ok... MsfG, Claudius | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
