[php] Textfiles contra DB für Gästebucheinträge

[Hinrich Donner]

Moin!

Actra AG Internet Services schrieb:

> A) Kann ich so die Gesamtzahl von MySQL-Queries aus dem Portal reduzieren

Die Frage dürfte abhängig von der Tatsache sein, welchen Sinn die 
Abfragen haben.

> B) Ist die Seite schneller, wenn die Daten aus kleinen Textdateien gelesen
> werden !?

Richtig. Egal, ob das Gästebuch in einer Datei oder in vielen Dateien in 
einem Verzeichnis sind, sie sind in der Regel bis zu einem begrenzten 
Volumen schneller. Bei ein paar 1.000 Gästebucheinträgen (= Dateien) 
sieht das schon anders aus.

> C) Sehe ich so direkt, welches Mitglied mit seinem Gästebuch wieviel
> Speicherplatz belegt

Das geht bei Datenbanken auch, wobei bei derartigen administrativen 
Abfragen die Performance in der Regel eine untergeordnete Rolle spielt.

> Meine Frage ist nun, ob diese Aussagen oben so auch zu treffen oder ob es
> bessere Gründe für die Speicherung der Gästebucheinträge in der MySQL
> Datenbank gäbe? 

Es gibt immer viele Für und Wider. Bei 10.000 Mitgliedern ist die 
Wahrscheinlichkeit hoch, wenn es aktive Mitglieder sind, dass zur selben 
Zeit auf ein Datum zugegriffen wird. Hier haben Datenbanken hinsichtlich 
der Konsistenz einen klaren Vorteil.

Von der Programmierung her bedeuten Textdateien ein zweites Interface, 
sofern auch Datenbanken unterstützt werden. Das erhöht den Aufwand und 
die Fehlerträchtigkeit. Wenn ich 99% der Daten in einem SQL-Server 
verwalten muss, habe ich ausgefeilte Routinen, die mich dabei 
unterstützen. Es macht dann wenig Sinn, noch ein Interface für 
Textdateien zu schreiben, nur für ein paar ms.

Wenn die Daten relativ dynamisch sind (beispielsweise Verküpfungen mit 
Daten, die durch die Ansicht eines Gästebucheintrages aktuallisiert 
werden (Visits, Sortierbarkeit etc.), kann die Nutzung der Datenbank 
sinnvoller sein.

> Gibt es ein Limit von der Grösse dieser Textdateien, das diese nicht
> überschreiten sollten, da es ansonsten zu Problemen kommen könnte? Zum
> Beispiel 2000 Einträge oder so...

4,irgendwas GB bei den meisten Systemen heute, aber das Limit gilt auch 
für Datenbanken. Probleme dürften aber deutlich vorher auftreten, 
spätestens wenn die Festplatte voll ist. Eine sinnvolle 
Wartungstätigkeit (Ändern statischer Daten) dürfte so um und bei 5000 
Datensätzen liegen. Da PHP eine Skriptsprache ist, deren Speicher i.d.R. 
auf 8MB begrenzt ist, ergeben sich auch daraus Laufzeit- und 
Größenbeschränkungen. Bei einem SQL-Server kann ich die Abfrage bereits 
begrenzen, nutze für die Filterung den SQL-Server (also Maschinencode) 
und kann so die Resourcen-Begrenzungen umgehen. Kleine Datenhäppchen von 
50 oder 200 KB sollten aber meistens über Textdateien schneller zu 
bearbeiten sein.

> Gäbe es dafür eine schönere Lösung, um einzelne Einträge zu löschen? Die
> Einträge sind im Textfile ungefähr in dem Format:

Ich würde einzelne Dateien je Eintrag nehmen, um das Löschen zu 
optimieren. Auch bei einem sutomatischen Verfall wäre man mit einer 
solchen Lösung im Vorteil. Bei einem ext2-Dateisystem würde man aber ab 
rund 2.000 Dateien ins Hintertreffen geraten, da das System dann langsam 
wird. Dafür wäre es Resourcen schonend. Bei den oben genannten 
8MB-Speicher-Limit wäre eine Datei ab rund 2 bis 4MB (je nach 
vorhandenen Extensions und Skriptgröße) nicht mehr lesbar.

> Oder befinde ich mich ohnehin mit der Gesamtlösung auf einem Holperweg?

Nein, der Weg ist brauchbar. Lediglich die Sonderzeichen (auch die 
eigenen) müssten konsequent maskiert werden. Hier würde ich, gerade bei 
Gästebüchern, den Datensatz als Array oder Objekt speichern, 
serialisieren (ja, ja, Bugs in PHP sind kein Argument für eine Lösung) 
und dann durch den Kompressor (vorzugsweise bzip) jagen. Das Rohformat 
ist hinterher leicht zu handeln, kompakt auf der Platte, aber nicht so 
einfach lesbar.

Aber die Frage, ob Datenbank oder Textdatei, die würde ich von der 
Datenmenge abhängig machen. Bei 10.000 Datensätzen wäre mir eine 
SQL-Variante mit statischem Cache lieber als eine Variante, die auf 
Textdateien basiert.

Hinrich