Halihallo Struppi
Was ich meinte ist, du kannst mit Storable nur ein Variabel auf einmal speichern und lesen.
Man braucht _nie_ mehr ;)
Und was ich nur im 1.Posting andeutete, verwende ich Data::Dumper und DB_File genmeinsam, um komplexere Strukturen abzuspeichern und zu laden.
Komplexität hat _gar nichts_ mit der "Anzahl von Variablen" zu tun. Ich kann dir eine
wunderschön Komplexe Datenstruktur in eine Variable packen... Im Gegenteil, es ist eben
nicht komplex und meistens unsauber programmiert, wenn man mehrere "Variablen" benötigt.
Du kannst mit einer Referenz auf einen Skalar, Array, Hash, Code, ... alles abbilden.
Das einzige, was Storable von Data::Dumper in unserem Sinne unterscheidet ist, dass
Storable eine Referenz als Input _erwartet_, bei Data::Dumper bist du da frei; dies als
Vorteil zu sehen ist jedoch falsch.
Also die einzelnen Strukturen des Hash per Dumper speichern und mit eval einlesen. Das ist herrlich flexibel (und ich hoffe bei meinen Datenbanken noch halbwegs performant)
Hast du dich wirklich über Storable informiert? - Das kann nämlich mindestens gleich
viel, ist jedoch noch wesentlich schneller.
Ich hab grad in der MLDBM Doku gelesen, das auch dort mit Data::Dumper gearbeitet wird, allerdings Storable (wegen Geschwindigkeit) empfohlen wird.
Aha, die werden sich wohl schon was dabei überlegt haben, oder? ;)
use Data::Dumper;
my $test ="system dir";
my $VAR1 = Dumper($test);
eval $VAR1;Da passiert nichts.
Eben doch. In $VAR1 hast du dann '$VAR1 = "system dir"' stehen und dieser Ausdruck,
wird zuerst geparsed, dann in einen Perl-Parsed-Tree umgewandelt und wie ein normales
Perl-Programm ausgeführt... Klar, dass der Befehl "system dir" nicht ausgeführt wird,
aber es findet ein allokieren von Speicher für die Variable $VAR1 statt, dann wird
ihr eine neue String-Konstante zugewiesen.
Das geschieht zwar auch etwa in Storable, nur dass da nicht der Perl-Parser anspringt und
versucht ein lauffähiges Script zu interpretieren, sondern ein sehr viel schlankerer
Code, der einfach gewisse Datenstrukturen einliest und _das_ ist der Geschwindigkeits-
gewinn (Stell dir vor: Dein eval $VAR1 überprüft gar die Syntax des Dumper outputs und
versucht den "Perl-Code" zu optimieren! - Bei Storable ist das ziemlich viel einfacher,
da man es _ausschliesslich_ mit Daten zu tun hat; der Output von Dumper _ist_ ein
_lauffähiges_ Perl-Programm).
Naja, ich glaube du hast jetzt verstanden, warum ich so gegen Data::Dumper interveniert
habe ;)
Viele Grüsse
Philipp