[Cologne-pm] Datenuebergabe von einem CGI-Scriptaufruf zum naechsten

[Michael Lamertz]

On Sun, Jul 06, 2003 at 03:59:35PM +0200, Joachim Zobel wrote:
> > > Weil sie den Weg zur First Row Performance verbauen können.
> > 
> > Klar, aber in einem solchen Trivialfall braucht man auch kein Caching.
> > Ich hatte da eher 'was mit Database-Links und diversen Joins im Auge. :)
> 
> Trivialfälle sind die Mehrheit :-)

Und in der Mehrheit der Faelle braucht man kein Caching :)

Ernsthaft:  Caching ist optimierung.  Das macht man erst dann, wenn
abzusehen ist, dass es eng wird, und der Code stabil ist.

Eine stelle an der ich mit sowas 'mal zu tun hatte, war ein
Navigationsbaum in 'ner Auktion.  Die haben das Ding bei *JEDEM* hit
wieder vollstaendig aus der DB aufgebaut - mit einer schoenen rekursiven
Suche durch die Produktkategorien.  Mathematisch einwandfrei, aber
leider sehr realitaetsfremd.

    (/me winkt Ludger zu, mit dem zusammen ich nach Muenchen musste, um
    die schuldigen zu vertrimmen.)

> > > Wenn man nicht von vorneherein die Resultsets mit einer Blockstruktur
> > > versieht, ist man am sehr schnell in der Situation, das man hin und
> > > wieder 1000 Sätze in den Resultset packen muss, um 10 anzuzeigen.
> > 
> > Den Satz versteh' ich nicht.  "Blockstruktur"?  Tell me more...
> 
> Wenn man grosse Resultsets hat und seitenweises anzeigen mit Blättern
> implementieren will, macht es Sinn, den Resultset mit Zeilennummern zu
> versehen. Man holt dann bei jeder Abfrage die Zeilen, die noch nicht im
> Resultset vorhanden sind neu und fügt sie ein. Wenn die Abfrage ihre
> Seite an den Browser geschickt hat, holt man die Zeilen für die
> Folgeseite.

Hmpf, jetzt sind wir aber wirklich bei Trivialfaellen, oder?  Wie machst
Du das denn bei Resultsets die aus komplexen Suchen entstehen?  Da
kannst Du doch mit festem Paging ueberhaupt nix reissen.

> Dsa gute an der (klassischen) Apachearchitektur ist, das sie Zustand auf
> dem Webserver schwierig macht. Aller Zustand ist entweder in der
> Datenbank oder auf dem Client.

/me versteht nicht, was das mit Apache zu tun hat.  Statelessness (*g*)
ist ein generelles Architekturproblem, aber dafuer gibt's ja die ganzen
Serverseitigen Frameworks wie mod_perl/_python/_snake/_ruby/..., oder
auch FastCGI (womit ich frueher ganz gute Erfahrungen gemacht habe).

Das soll beileibe kein Argument gegen Deine Kernaussage bzgl. der
Ablagestelle von State sein.  Nur ein Hinweis, dass es techniken um den
Kram zu vermasseln auch schon lange gibt.

-- 
	    Well, then let's give that Java-Wussie a beating... (me)

Michael Lamertz                        |     +49 2234 204947 / +49 171 6900 310
Sandstr. 122                           |                       mike at lamertz.net
50226 Frechen                          |                 http://www.lamertz.net
Germany                                |               http://www.perl-ronin.de