Lange Texte in DB?

[Ina]

Hi, eine vereinfachte Usertabelle aus (id, name, pass, txt).
Der Text könnte allerdings tausende Zeichen beinhalten.

Wäre es dann noch klug den in der DB zu integrieren oder besser doch als File zu speichern und in DB nur den Verweis dazu?

Ich meine damit nicht 100-200 User, sondern tausende User und eine Mindesttextlänge von umgerechnet einer Din-A4-Seite.

Auch eine Frage zur DB, macht es einen besonderern Unterschied ob mysql oder sqlite, mal abgesehen von den normalen Unterschieden der beiden Datanbankmodelle, in diesem Fall.

Gruss
Ina

[trunx]

Hi,

solche langen Texte würde ich in eigene files abspeichern und lediglich den Speicherort in der DB niederlegen (analog zu Bildern).

bye trunx

[Sven Rautenberg]

Moin!

solche langen Texte würde ich in eigene files abspeichern und lediglich den Speicherort in der DB niederlegen (analog zu Bildern).

Würde ich absolut nicht machen.

Man kann darüber nachdenken, ob es sinnvoll ist, eine eigene Tabelle für diese Texte anzulegen, die 1:1 mit der Usertabelle verknüpft wird. Das ist dann sinnvoll, wenn dadurch die Usertabelle günstigere Indices kriegen kann, oder wenn die Texte nicht allzu häufig gelesen werden.

Im Gegensatz zu Grafiken werden diese Texte jedoch niemals "nackt" vom Server abgerufen, das Speichern in der Datei bringt also keinerlei Vorteil, sondern im Gegenteil sogar den extremen Nachteil, dass man sich selbst Gedanken um eine effiziente Verzeichnisstruktur machen muß, und dadurch eventuell sogar ziemlich viel Performance verschwendet, sollte das Dateisystem für diesen speziellen Anforderungsfall nicht gut vorbereitet sein (Clustergröße, Inode-Dichte, Verzeichnislisting etc...).

- Sven Rautenberg

[Tom]

Hello,

Im Gegensatz zu Grafiken werden diese Texte jedoch niemals "nackt" vom Server abgerufen, das Speichern in der Datei bringt also keinerlei Vorteil, sondern im Gegenteil sogar den extremen Nachteil, dass man sich selbst Gedanken um eine effiziente Verzeichnisstruktur machen muß, und dadurch eventuell sogar ziemlich viel Performance verschwendet, sollte das Dateisystem für diesen speziellen Anforderungsfall nicht gut vorbereitet sein (Clustergröße, Inode-Dichte, Verzeichnislisting etc...).

Vielleicht solltest Du das "nackt" nochmal etwas ausführlicher darstellen.
Ich verstehe Dich so, dass in der Tabelle nur die Rohdaten gespeichert werden.
Um diese darstellen zu lassen, müssen sie erst kontextgerecht behandelt werden,
müssen also sowieso durch die API gezogen werden.

Bei Bildern ist das anders, die liegen bereits im "Auslieferformat" vor und sollen deshalb möglichst nicht durch die API gezogen werden.

Ina sollte hier mMn ihrer Entscheidung eine Kalkulation der Datenmengen vorausschicken.
Ein modernes Filesystem sollte Datenblöcke in 1k-Schritten als maximale Zuordnungseinheit verwalten. Eine DIN-A4-Seite hat ca. 2.000 Zeichen. Je nach Codierung und Inhalt, sowie ggf. Formatanweisungen können das also auch 8k Daten werden (oder mehr). In Zuordnungseinheiten von 1k zu arbeiten, ist daher also technsich angemessen.

Die Datenbank hat aber eine maximale Tabellengröße. Die Zugriffsgeschwindigkeit auf einzelne Datensätze hängt außerdem von der effektiven Speichernutzung ab, insbesondere beim Einsatz von Indexen. Es ist also nicht unbedingt ratsam, die Texte in derselben Tabelle zu halten, wie die indizierten Daten. Ein Join zur rechten Zeit macht den Zugriff ja möglich.

Trotzdem sollte Ina sicherlich bedenken, dass auch die ausgelagerte Tabelle nur eine endliche Größe haben kann. Leider kann ich die aktuellen Limits bezüglich Tabellengröße bei MySQL (als Besipiel) zur Zeit nicht entdecken. Die 4GByte-Grenze für übliche DBMS habe ich noch im Hinterkopf.

Ein harzliches Glückauf

Tom vom Berg