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
put serial(%hash), "bla.htx";
|
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.
%hash=eval get "bla.htx";
|
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.
@kinder=("Barbara", "Ingrid", "Stefan");
put ["Name", "Hans", "Kinder", serial(@kinder)], "leute";
|
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.
get "Name==!Hans", "leute";
@kinder=eval $Kinder; out "Kinder von $Name: @kinder";
|
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:
%cds= ( "lc1109" => { "Interpret" => "Underworld", "Titel" => "dubnobasswithmyheadman", "Preis" => 19.95 },
"lc0121" => { "Interpret" => "Phil Collins", "Titel" => "Face Value", "Preis" => 12.95 },
"lc0485" => { "Interpret" => "The Police", "Titel" => "Zenyatta Mondatta", "Preis" => 14.95 } );
put ["Name", "Concrete Record Store", "Sortiment", serial(%cds)], "plattenlaeden";
|
speichert den Hash
%cds im Feld
Sortiment in der Datenbank
plattenlaeden.
Hier das Auslesen:
while(get "Name~=c", "plattenlaeden") { out "<b>Laden: $Name</b><br>"; %cds=eval $Sortiment; foreach $nr (sort keys %cds) { $cds=$Sortiment{$nr}; out "Nummer: $nr, Interpret: $cds{Interpret}, Titel: $cds{Titel}, $cds{Preis}<br>"; } out "<br>"; }
|
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.
 | Beachten Sie |
Das obige Beispiel ist gleich eines, das eine mögliche "Fehlanwendung" dieser Funktionalität verdeutlicht. Was ist, wenn man später alle CDs deren Interpret mit "p" anfängt ausgeben lassen will? Das ist mit obiger Umsetzung nicht oder nur mit sehr viel unnötigem Aufwand möglich.
In den meisten Fällen sollte man für dieses Beispiel eine zusätzliche Datenbank mit den CDs anlegen und Relationen zwischen den beiden Datenbanken herstellen.
|
|