Halihallo Struppi
Äm, sorry, aber das ist zwar funktional aber völliger Schwachsinn.
Wenn du schon komplexe Datenstrukturen speichern willst, dann verwendeperldoc Storable;
aber ein aperformantes generieren eines schönen Abbildes der Datenstruktur und ein
aperformantes einlesen über kurriose eval's (was bei Attacken auch lauffähiger Perl-Code
sein könnte) ist schlicht, naja etwas viel "Overhead" ;)
Bevor ich den Umstieg auf mySQL gewagt habe, habe ich meine "Datenbanken" immer so benutzt. Storable hat den Nachteil, das ich alle Daten einlesen muss, was wohl selbst bei einer kleinen DB nicht unbedeutsam ist.
Wieso? - Storable liest genauso die ganze Datei ein, wie du auch über deinen Lösungsweg
machen musst. Zudem hat Storable ein C-Backend, was es doch ganz schön schnell macht,
eval hingegen (wohl auch auf C basierend...) muss den eingelesenen String zuerst
parsen, dann wird er in einen Perl-Parsed-Tree umgewandelt und dann interpretiert, wie
das mit allen Perlprogrammen geschieht; das macht die Sache eben langsam.
eval sollte aber keine Probleme machen, da der Inhalt ja nicht ausgeführt wird, sondern der output von Data::Dumper, der (oder verläßt mich da meine Vorstellungskraft) keinen Code enthält, sondern Strings, die die Datenstruktur darstellt.
Auch Strings gehören zu Perl und werden interpretiert, genauso wie Befehle. Natürlich
gibt es bei Data::Dumper nicht viel "auszuführen", dennoch wird der Code (und _das_ ist
er dennoch) zuerst geparsed und dann interpretiert, ob dies nun eine Variablendeklaration
oder ein Befehl ist, spielt Perl eigentlich keine Rolle.
P.S. ich teile so viel Kritik aus, da sollte man durchaus auch Kritik einstecken können ;-)
Das musst du positiv sehen! Kritik ist da um zu lernen, also bitte "schlag auch bei mir
rein" ;)
Viele Grüsse
Philipp