nicht angemeldet
Hello,
Das mit der Referenz klingt auch ganz einleuchtend. Obwohl ich für "die" tabelle, die ich gerade gemacht habe, garantiert nicht by diesem feld ordern möchte, d.h. "order by" wäre hierbei irrelevant. Verbraucht eine zusätzliche Referenz mehr Speicherplatz als ein im-stream-speichern oder nicht?
Eben nicht. Allerdings ist das alles nicht mehr generisch, sondern bei MySQL hat man schon gewaltig am Rad gedreht. Das beste Beispiel für den theoretischen Einstieg wäre dafür das gute alte dbase mit seinen Memofeldern. Eine dbase-Datei beteht dabei aus
Superhead (fix)
Head (variabel)
Body (enthält die Datensätze)
Memofile (separate Textdatei)
Im Body werden die Datensätze, deren Struktur im Head beschrieben wird, angereiht. Die Sätze haben feste Länge und feste Feldstruktur. Das wäre nun vergleichbar mit den CHAR-Feldern von MySQL. Wenn man nun Texte mit variabler Länge speichern will, wird in einem solchen Feld nur eine Referenz in die separate Datei abgespeichert, der Einsprungspunkt auf den Block dieser Datei. Die textdatei ist also (aus Geschwindigkeits- und Adressierungsgründen) ihrerseits in Blöcke eingeteilt. Die Größe kann man einstellen. Ob das bei MySQL auch geht, weiß ich nicht oder ob diese hier inzwischen byteweise auf Seiten verwaltet werden... Ich sagte ja, die haben sich da schon was einfallen lassen.
Jedenfalls ist es einleuchtend, dass eine referenzierte geblockte Speicherung im Mittel weniger Platz benötigt, wenn die Blöcke klien genug gehalten wrden, als wenn man für JEDEN Satz z.B. 4096 Byte vorrätig halten müsste, diese aber nur bei jedem zehnten benutzt.
Ich hoffe, meine wuselige Erklärung hat Dir trotzdem etwas Anregung gegeben. man müsste Bilder dazu malen, dann wäre es verständlicher.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau