Moin!

Die Menge an DB-Abfragen hingegen kann man bei Bedarf einer manuellen Optimierung unterziehen.

Es sind nicht viele DB-Abfragen, ich mach bestimmt wieder aus einer Fliege einen Elefanten.

Vermutlich. Optimiere nichts, was sich noch nicht als Problem erwiesen hat, denn jede vorzeitige Optimierung ist vermutlich falsch - also nicht bedarfsgerecht.

Von der Performance her ist die Auslieferung einer komplett statisch auf Festplatte liegenden Datei unschlagbar schnell. Aber diese Datei so zusammenzustellen, dass die Dynamic der Site realisiert wird ist programmtechnisch sehr aufwendig.
»»
Und wenn diese Datei nur erstellt wird, wenn es eine Datenbankveraenderung gegeben hat, ergo etwas in die Datenbank eingetragen werden musste und daraufhin die Datenbank per Script in eine HTML-Datei veraendert wird, und diese HTML-Datei dann includiert wird, gehoert dass auch zu der oben genannten Variante?

Eine Datenbankveränderung betrifft nur selten exakt eine einzige generierte Datei.

Nur mal angenommen, es wird die Navigation geändert: Dann müssten alle Seiten neu generiert werden. Das kann ein deutlich zeitaufwendigerer Vorgang werden, als das schlichte Aktualisieren der Datenbank. Und er ist in der Regel auch nicht so simpel durchzuführen. Die Schwierigkeit besteht hierbei üblicherweise im Problem, zu erkennen, welche Seiten von der Änderung alle betroffen sind.

Der Mittelweg würde bedeuten: Wichtige, häufige und selten veränderte Aufrufe der dynamischen Site werden in einem Cache gehalten. Viele von denen sind standardmäßig im Spiel, wenn man sie intelligent einsetzt, beispielsweise der MySQL-Query-Cache. Andere Caches kann man natürlich manuell ins Spiel bringen - sofern das Abrufen des Caches nicht langsamer ist, als der Originalvorgang (messen!).

Das Problem ist ja, ich weiss ja nicht, wie oft etwas geaendert wird. Kann man auch, bei einer Tabelle, die ganze Tabelle cachen und bei Bedarf (wenn es eine Aenderung in der DB gab) einen Zelleninhalt "updaten"?

Man wird heutzutage seinen Datenbankserver immer versuchen so zu konfigurieren, dass die gesamte Datenbank im RAM gehalten werden kann. Das gilt natürlich nicht unbedingt für Shared Hosting, aber definitiv für dedizierte Virtual Server und echte Server, die man vollständig selbst administrieren kann. Dadurch entstehen dann gerne mal Servercluster mit 64 GB RAM pro Maschine nur für die DB.

Solange du grundsätzlich noch kein DB-Performanceproblem HAST, solltest du dir über Optimierung noch nicht allzu sehr Gedanken machen.

Wie kann man eigentlich ein Skript, welches in einer anderen Datei liegt aufrufen und ihm Parameter uebergeben? Per include, oder gibt es da noch andere Wege?

Das würde man vermutlich versuchen zu vermeiden.
Also include ist in der hinsicht schlecht? Wie macht das dann, z.B. joomla?

Die problematische Stelle ist: Wie kommt ausführbarer Code in die Datei, die mit Include eingebunden wird? Ich würde dir pauschal zutrauen, dass du auf Anhieb mehr als eine Sicherheitslücke da reinprogrammierst. :)

- Sven Rautenberg