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

Joachim Zobel jzobel at heute-morgen.de
Sun Jul 6 08:59:50 CDT 2003


Am Fre, 2003-07-04 um 01.21 schrieb Michael Lamertz:
> On Thu, Jul 03, 2003 at 06:44:56PM +0200, Joachim Zobel wrote:
> > Am Don, 2003-07-03 um 00.36 schrieb Michael Lamertz:
> > > On Tue, Jul 01, 2003 at 10:08:48PM +0200, Joachim Zobel wrote:
> > 
> > > > Handgecachte Resultsets machen normalerweise mehr Probleme, als sie
> > > > nützen.
> > > 
> > > Wieso?
> > 
> > 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 :-)

> > 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.

Blockstruktur war unglücklich formuliert, Blöcke machen hier nur bei
fester Seitengrösse Sinn.

> > Generell sind Resultsets serverseitiger Zustand. Aller serverseitiger 
> > Zustand ausserhalb der Datenbank ist IMHO "böse". 
> 
> :)  Ich sehe, Du bist den Weg des Schmerzes bereits gegangen...  Mit
> so'nem Kram hab' ich auch gerade wieder zu tun.  WebSphere
> Applikationen, die jetzt Loadbalanced werden sollen, aber irgendwelche
> Pfeifen haben hart um die bereits eingebauten Mechanismen
> 'rumprogrammiert haben.  /me hates Java...

An der Stelle ist vermutlich aber nicht Java sondern Objektorientierung
Wurzel des Übels. Objektorientierung ist gut, um langlebige Komplexe
Zustände im Griff zu behalten. Damit selbige Sinn macht, müssen halt
langlebige komplexe serverseitige Zustände her. Seufz.

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.

Gruß,
Joachim

-- 
"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden 
koennen."                            - Bertolt Brecht - Leben des Galilei 




More information about the Cologne-pm mailing list