baseportal
Suche: 
 Forum   Start 

Komplexe Datenstrukturen speichern und ausgeben (Serialisierung)

ab Version 3 

Komplexe Datenstrukturen speichern und ausgeben (Serialisierung)

Das Aufbereiten komplexer Datenstrukturen wie Listen oder Hashes zur Speicherung in Datenbank-Feldern oder Dateien, nennt man Serialisierung. Die Listen oder Hashes können beliebig verschachtelt sein, so dass auch Listen von Listen oder Hashes von Listen von Hashes (oder ... ;-) ) möglich sind. Die Funktion dafür heisst serial. Ein spezielles Gegenstück zu serial gibt und braucht es nicht, denn der serialisierte Inhalt ist nichts anderes als Perl-Code, der -mit eval ausgeführt- eine entsprechende Liste oder einen entsprechenden Hash erzeugt: speichert die Liste @liste in serialisierter, komprimierter Form in der Variablen $ser. erzeugt die in $ser gespeicherte Liste wieder. Nun macht obiger Code an sich wenig Sinn, da die Liste ja schon existiert. Interessant wird es, wenn man die serialisierte Form speichert:

In Dateien speichern

speichert den Hash %hash in der Seite bla. Die Klammern braucht es, da "bla.htx" sonst dem Hash zugerechnet würde und nicht als Parameter für put. liest den gespeicherten Hash wieder ein.

In Datenbanken speichern

Auch das Speichern in Datenbankfeldern geschieht denkbar einfach. Dabei weiss die Datenbank garnichts davon, dass in einem Feld z.B. eine Liste gespeichert ist; sie sieht nur den serialisierten Code. Folglich wird es zu Problemen oder unerwarteteten Ergebnissen kommen, wenn eine Serialisierung in bestimmte Feldtypen wie "Zahl" oder "EMail" geschrieben wird - diese überprüfen z.B. die Eingabe auf Korrektheit (Ist es eine Zahl? Ist es eine EMail-Adresse?), was mit der serialisierten Form nicht funktionieren kann. Auch eine Sortierung wird nicht klappen. Am Besten verwenden Sie für Felder, in denen Sie Listen oder Hashes speichern wollen die Feldtypen text oder textarea. speichert die Liste @kinder im Feld Kinder in der Datenbank leute. Die Klammern beim serial sind in diesem konkreten Fall zwar nicht unbedingt zwingend, aber wenn dahinter weitere Felder kommen sollten, sind sie zur Abgrenzung nötig. gibt die Kinder von Hans aus. Komplexe Datenstrukturen in Datenbankfeldern können in vielen Fällen "klassische" Relationen ersetzen. Gerade für 1:n-Beziehungen (Alle Kunden eines Kundenberaters) bietet sich das Speichern der entsprechenden Ids in einer Liste an. Das hat viele Vorteile, u.a. einen direkten Zusammenhang (die Daten stehen gleich im zugehörigen Datensatz) und es ist keine spezielle Datenbank für die Relationen notwendig. Sollen auch Rückbezüge möglich sein, müssen diese allerdings zusätzlich in der zweiten Datenbank gespeichert werden. Diese Information ist dann somit doppelt vorhanden, was wieder Vor- und Nachteile hat. Ob man nun die "klassischen" Relationen mit einer dritten Datenbank für die Beziehungen verwendet, oder die Beziehungen mit einer komplexen Datenstruktur gleich bei den Einträgen speichert, hängt vom Einzelfall und dem persönlichen Geschmack ab. Dasselbe wie mit Listen funktioniert genauso mit Hashes, hier gleich in einer verschachtelten Ausführung: speichert den Hash %cds im Feld Sortiment in der Datenbank plattenlaeden. Hier das Auslesen: liest alle Einträge der Datenbank plattenlaeden die mit c beginnen und gibt deren Name, sowieso alle CDs (Interpret, Titel und Preis) im Sortiment aus.
Alte Version vom 22.9.2006, 19:26 - Stichworte: Serialisierung, serial, Komplexe Datenstrukturen, Hash, Arrayc und wiederherstellen - +

© baseportal GmbH. Alle Rechte vorbehalten.


powered in 0.01s by baseportal.de
Erstellen Sie Ihre eigene Web-Datenbank - kostenlos!