Website DB-basiert versus Filebasiert

[himitsu]

Ich benutzte quasi ein halbes DB-basiertes System, da die Seiteninhalte in der DB liegen und der Rest (Bilder usw.) im Dateisystem.

Im Grunde könnte man ein DB-basiertes System mit nur einer einzigen winzigen PHP-Datei erzeugen, welches Alles (HTML, Bilder, CSS, JS usw.) aus der DB zieht.

Der Vorteil bei einem reinen statischen dateibasierten System wäre, daß man eben keine DB brauch und praktisch keine Sicherheitslücke existiert, wenn im Webserver kein Code ausgeführt wird. (solange der FTP- und der HTTP-Server sicher sind)

Was man bei der Webseite erstmal betrachen sollte, ob CMS oder nicht.
Es gibt immernoch genügend Leute, welche auf dem PC die Webseite bearbeiten/generieren und dann via FTP hochladen,
während andere eben ein sich selbt bearbeitbares CMS bevorzugen.


Wie bereits erwähnt, kann man das Schneller nicht beantworten, ohne die genaue Webseite, deren Daten und auch den Server zu kennen.
Werden die Daten life generiert (bei jedem Zugriff) oder gibt es eine Cache, bzw. ein Zwischending, wo nur gewisse Teile vorgeneriert/gecached sind
oder sind alle Daten bereits fertig auslieferbar?
Bei Letzterem kommt es dann nur noch daauf an, wie schnell der Speicher (Dateisystem oder DB) die Daten liefern kann.

Man nehme nur mal das alte QC von Borland/Embarcadero, wo am anderen Ende kein "normaler" Webserver, sondern ein Delphiprogramm hängt.

PS: http://www.opensourcecms.com/

[Delbor]

Hi himitsu

Zitat von himitsu:

Was man bei der Webseite erstmal betrachen sollte, ob CMS oder nicht.
Es gibt immernoch genügend Leute, welche auf dem PC die Webseite bearbeiten/generieren und dann via FTP hochladen,
während andere eben ein sich selbt bearbeitbares CMS bevorzugen.

Das Webserverprogramm wird mit Delphis Webbrokertechnologie erstellt, wie ich oben schon geschrieben habe. Ich hab mir sagen lassen, dass das schon ein CMS ist. Da ich Typo3 halbwegs kenne, wollte ich es allerdings nicht so nennen.

Zitat von himitsu:

Werden die Daten life generiert (bei jedem Zugriff) oder gibt es eine Cache, bzw. ein Zwischending, wo nur gewisse Teile vorgeneriert/gecached sind
oder sind alle Daten bereits fertig auslieferbar?
Bei Letzterem kommt es dann nur noch daauf an, wie schnell der Speicher (Dateisystem oder DB) die Daten liefern kann.

Die Daten werden life per Stream generiert - entweder vom DB-BlobStream oder von einem Filestream an den Webbroker ContentStream übergeben. Dabei gibt es einen Stream, der die eigentliche Webseite liefert, einen HTML-MenueStream, einen CSS-MenueStream und je einen Stream für die anzuzeigenden Fotos.

Um meine Dateien auf den Server hochzuladen, habe ich WebMatrix zur Verfügung.

Gruss
Delbor

PS:

Zitat:

oder gibt es eine Cache, bzw. ein Zwischending, wo nur gewisse Teile vorgeneriert/gecached sind

Nein, bislang gibt es keinen Cache. In Bezug Caching werde ich mich noch genauer informieren müssen - Webbroker selbst cacht zwar auch, aber nur bis zur Auslieferung.

[Phoenix]

Aus Erfahrung (ich baue die letzten 5 Jahre ein CMS) kann ich sagen, alles, was Du aus Dateien ausliefern kannst, solltest Du auch auch Dateien ausliefern.

Zumindest, wenn das was Du auslieferst, auch einigermassen schnell sein soll.

Filebasiert hat viele Vorteile: Der Webserver und auch das Betriebssystem darunter haben viele Möglichkeiten das Zeug intern zu cachen.
Wenn Du Files da liegen hast, dann kann der Webserver zu Deinen Dateien die richtigen Cache-Header setzen (z.B. E-Tag, last Modified) und kann anhand der Fileangaben auch automatisch die richtigen Header zurücksenden (z.B. 304 Not Modified). Das ganze müsstest Du sonst für dynamischen Content alles selber bauen. Also sowohl das interne cacheing vor der Auslieferung als auch das korrekte Handling der Http Caches.

Statischer Content hat noch mehr Vorteile: Du kannst das, was statisch dort liegt, besser skalieren und ausfallsicher gestalten. Einfach das gleiche Zeug auf mehrere Webserver klatschen, ein Loadbalancer-Pärchen vorne dran, und gut ist. Wenn eine Kiste oder ein LB ausfällt übernimmt einfach ein anderer und gut ist.

Zudem braucht sowas natürlich deutlich weniger CPU und RAM, als wenn das alles zur Laufzeit berechnet werden muss. Das heisst man kann mit weniger Hardware eine deutlich größere Menge an Usern versorgen.

Lieferst Du dynamisch aus, musst Du zusätzlich noch dafür sorgen das auch die Datenbank ausfallsicher bereitgestellt wird. Denn fällt die DB aus, liefert Deine Anwendung sonst gar nichts mehr aus. Das erhöht die Komplexität der Systems um einiges. Und dann stellt sich die Frage: Kommt die Anwendung selber ohne Statushaltung aus? Wenn Du im Code sowas wie Sessions benutzt um den Zustand des Clients zu speichern, dann musst Du auch in der Lage sein, das irgendwo hin zu persistieren, für den Fall das ein Webserver ausfällt.

Das heisst natürlich nicht, das man zur Verwaltung hier keine DB nutzen sollte.
Aber ein Verfahren, das aus dem Inhalt in der DB den auszuliefernden Content (= die HTML-Generierung) nicht zur Laufzeit macht, sondern aus dem DB-Inhalt alles statisch vorgeneriert und dann lediglich ins Filesystem zur Auslieferung legt, ist der volldynamischen Generierung beim Request vorzuziehen.

Wie gesagt sowohl zur besseren Nutzung von Ressourcen (Hardware), zum besseren Handling von Skalierung und Ausfallsicherheit, als auch zur besseren Ausnutzung der eigentlich für die Auslieferung von statischem Content optimierten Webserver.

Man kann das natürlich auch mischen. Alles was geht, aus files, und wenn dann wirklich was dynamisch generiert werden muss, diesen Teil auf das nötigste beschränken. Ist letzten Endes immer ne Fallentscheidung, aber so als Richtlinie sollte man immer versuchen, Dateien den Vorzug zu geben.

[sx2008]

Ein Dateisystem ist übrigens auch eine Datenbank und zwar handelt es sich um eine Key-Value Datenbank.
Der Key ist der Dateiname inklusive Pfad und der Value ist der Inhalt der Datei. Die API ist im Betriebssystem integriert und Managementtools sind auch schon an Bord.

Man benötigt nicht immer eine relationale Datenbank sondern gerade bei Webserver reicht meistens eine NoSQL Datenbank aus.

Wenn man z.B. MySQL nur dazu verwendet um statische Blobs (z.B. JPegs, Html, Javascriptdateien) zu speichern und die Features von SQL (Joins, Aggregatfunktionen, Views,...) nicht in Anspruch nimmt dann hat man das falsche Werkzeug benützt.
Möchte man ein Forum abbilden (mit User, Benutzerechten, Unterforen, Tags, Suchfunktion,...) dann ist eine relationale Datenbank natürlich sehr nützlich. Es kommt halt immer auf die Anwendung an.

PS: statische Inhalte - also Dateien die vom Entwickler der Webseite erstellt wurden - sollte man immer als Dateien und nicht in einer rel. Datenbank speichern.

[Delbor]

Hi zusammen
Erst mal vielen Dank für eure ausführlichen Antworten. Sie enthalten interessantes Futter für meine grauen Zellen

Zitat:

Aus Erfahrung (ich baue die letzten 5 Jahre ein CMS) kann ich sagen, alles, was Du aus Dateien ausliefern kannst, solltest Du auch auch Dateien ausliefern.

Also fällt eine komplett DB-basierte Webserveranwendung aus. In einer DB wären allenfalls Angaben über registrierte Nutzer, ausgelieferte Cookies(?) etc abzulegen.
Ein Argument pro DB meinerseits war, dass die Daten da etwas besser vor Angriffen geschützt sein dürften.

Allerdings muss ich doch nochmal nachfragen; die Unklarheiten betreffen die Begriffe 'statisch' unhd 'dynamisch'. Unter statisch verstand ich bislang eine Webseite, die schon fix und fertig auf dem Server vorliegt, also mit dem kompletten HTML, CSS und allenfalls Javasript, bzw. verweisen im HTML zu Dateien, die CSS oder Javascript enthalten.
Unter 'dynamisch' verstand ich Webseiten, die zB. von Webbroker zusammengebaut werden. Hier kann ja die durch Platzhalter gekennzeichnete Stelle im HTML-String durch beliebige andere Inhalte ergänzt werden - einen CSS-String, der den Hintergrund rot färbt oder einen anderen, der grün färbt zum Beispiel.

So gesehen, wären meine Webseiten immer dynamisch, auch wenn Änderungen im Code nicht vorgesehen werden. Egal, ob die entsprechenden Inhalte aus einer Datei oder einer Datenbank (auf dem Server) stammen.

Zitat:

Das heisst natürlich nicht, das man zur Verwaltung hier keine DB nutzen sollte.
Aber ein Verfahren, das aus dem Inhalt in der DB den auszuliefernden Content (= die HTML-Generierung) nicht zur Laufzeit macht, sondern aus dem DB-Inhalt alles statisch vorgeneriert und dann lediglich ins Filesystem zur Auslieferung legt, ist der volldynamischen Generierung beim Request vorzuziehen.

Auf meinem Rechner läuft meine (Bild-)Datenbankapplikation(MySQL), mit deren Hilfe ich HTML-Seiten per Drag&Drop zusammmenstellen kann. Diese sollen dann per Webdav in meinem Webaccount auf dem Server abgelegt werden. Auf dem Server soll eine Webbroker-Anwendung laufen, die aus diesen Dateien die Webseiten zusammenbaut.
Konkret heisst das: es gibt eine TPageproducer, die Anhand des Requests eine bestimmte HTML-Seite lädt. An bestimmten Stellen des HTML-Strings sind Platzhalter eingefügt, die Webroker mit CSS, Bildaten etc ersetzt, indem er diese Daten per Filestream ausliest, wobei für HTML,CSS etc. jeweils eigene TPageproducers zuständig sind.
Wenn ich obiges Zitat richtig verstanden habe, plädierst du allerdings für ein Verfahren, das eine Datei vorsieht, die gleich nebst Html auch CSS und Javascript enthält und demnach nur noch die Bilder eingebunden werden müssen.

Gruss
Delbor

[himitsu]

Zitat:

Ein Argument pro DB meinerseits war, dass die Daten da etwas besser vor Angriffen geschützt sein dürften.

eigentlich schlechter

Nur Dateisystem:

• man muß irgendwie auf die Dateien zugreifen
  > dein Programm, HTTP-Server, FTP-Server, PHP-Engine, ...

In Datenbank:

• man muß irgendwie auf die Datenbank zugreifen
  > DB-Server
• aber man kann auch einen DB-Befehl einschleusen
  > dein Programm, HTTP-Server, FTP-Server, PHP-Engine usw.

Insgesammt also nochmal ein zusätzlicher Angriffspunkt.

[p80286]

Zitat von sx2008:

Ein Dateisystem ist übrigens auch eine Datenbank und zwar handelt es sich um eine Key-Value Datenbank.
Der Key ist der Dateiname inklusive Pfad und der Value ist der Inhalt der Datei. Die API ist im Betriebssystem integriert und Managementtools sind auch schon an Bord.

Man benötigt nicht immer eine relationale Datenbank sondern gerade bei Webserver reicht meistens eine NoSQL Datenbank aus.

Wenn man z.B. MySQL nur dazu verwendet um statische Blobs (z.B. JPegs, Html, Javascriptdateien) zu speichern und die Features von SQL (Joins, Aggregatfunktionen, Views,...) nicht in Anspruch nimmt dann hat man das falsche Werkzeug benützt.
Möchte man ein Forum abbilden (mit User, Benutzerechten, Unterforen, Tags, Suchfunktion,...) dann ist eine relationale Datenbank natürlich sehr nützlich. Es kommt halt immer auf die Anwendung an.

PS: statische Inhalte - also Dateien die vom Entwickler der Webseite erstellt wurden - sollte man immer als Dateien und nicht in einer rel. Datenbank speichern.

Könnte man dieses Statement irgendwie an prominenter Stelle als allgemein gültige Aussage ablegen?
So als "Grundlage der Programmierung"?

Gruß
K-H

[Sherlock]

Beispiel für dateibasierten Webauftritt: Wir nutzen in der Firma DokuWiki für unser internes Wiki. Das ist von den Inhalten her komplett Dateibasiert und richtig zügig. Es gilt bei denen als Feature, daß es keine DB braucht, da es damit leichter in die vorhandene Infrastruktur integrierbar ist. Es ist quasi nur ein gängiger HTTP-Server nötig (bei uns Apache). Ich find den Gedanken charmant, daß im Katastrophenfall, keine DB-Files zu rekonstruieren wären, sondern "nur" Textdateien.

Sherlock

[Delbor]

Hi zusammen

Zitat:

Das ist von den Inhalten her komplett Dateibasiert

Also auch die Infos über registrierte User etc.? Könnte ich sogar lösen, ohne meine grauen Hirnzellen zu sehr in Bewegung zu setzen, da ich Ergebnisse von Selectabfragen in einer eigenen Klassen ablege, deren Instanzen die komplette Tabellenstruktur darstellen und so einen auf mehrere Tabellen verteilten DS aufnehmen.
Das ist eine ernsthafte Überlegung Wert.

Gruss
Delbor