Querys vs. statische Codegeneration

[pzypher]

Hallo,

ich habe folgende Verständnisfrage:

Eine HTML Seite, die Content aus einer DB enthält. Der Content ist nicht benutzerabhängig und ändert sich jeden Tag. Ich überlege wie ich das nun umsetze:

• Erzeugung des Contents mit DB Querys, also bei jedem Seitenaufruf die gleiche Abfrage
• "Statische" Codegeneration, z.B mittels Java (Statischer HTML Code + Variablen (= DB Querys nur einmal bei der Seitenerzeugung))

Wäre Zweiteres nicht sinnvoller, da der Content ja sowieso "fix" ist und die DB nicht beansprucht wird - ein Seitenaufruf daher theoretisch schneller ist?

Gruß

 

[Bernd Hohmann]

Die Antwort ist "hängt davon ab". Wenn Du in Deiner Anwendung noch mehr dieser "ändert sich nur 1x am Tag"-Seiten hast und die Seitenerzeugung aufgrund der komplexen Daten ordentlich auf die CPU geht, dann würde ich die Seite 1x am Tag erzeugen und dann statisch ausliefern.

Ansonsten halt bei jedem Seitenaufruf neu generieren.

Bernd

 

[ARadauer]

Wie oft wird die seite am tag aufgerufen?... Man muss keine handstände für 200 queries am tag machen...

 

[pzypher]

Noch gar nicht ;-)

Man stelle es sich folgender Maßen vor:

Mein Java Programm durchsucht Videoseiten a la Vimeo nach Videos mit gewissen Inhalten. Diese Daten inkl. embed-Code des Videos werden in eine DB geschrieben. Es soll sowohl für das embed-Video eine eigene Seite erstellt werden, als auch jeden Tag eine aktuelle Übersichts/Startseite mit allen neuen Videos.

Die Übersichtsseite ist glaub ich leichter per Queries zu realisieren. Doch die einzelnen Videoseiten würden ja bei Realisierung mittels Queries noch nicht einmal erzeugt worden sein (?) - d.h. stell ich mir schwieriger vor.

 

[Bernd Hohmann]

Also in diesem Fall würde ich mich durchgehend auf dynamische Erzeugung der Seiten stützen, oder auf das was Dir am einfachsten erscheint.

Wenn das Projekt irgendwann mal zum Überflieger wird kann man sich immer noch dem Nutzerverhalten anpassen.

Aber schön dass Du vorher über das nachher denkst - machen zu wenige.

Bernd