Natuerlich wuerde ich serializer benutzen, die sicherheit ist halt eine frage der Zugriffsrechte.
Es koennte sonst ja auch jemand an deinem Skript manipulieren... ;)

Ausserdem ist SQLite fast immer zur hand.

Die Frage nach der nicht vorhandenen relationalen Datenbank:

In so einem Fall sind die Daten oft einfach strukturiert.
Meistens schreibe ich da ganz primitiv:
name1="wert1" name2="wert2"\n
Da kann ich es auch manuell wieder lesen. Dann parse ich die Daten über einen regulären Ausdruck einfach wieder rein. Das geht auch ziemlich schnell. Oder ich nehme Text::CSV, dann kann man sich das gut mit Excel anschauen. Die Frage nach der Manipulation hat sich bei mir noch nicht so gestellt, weil das oft durch die Rechte an der Datei formuliert ist.

Das mit der Datei und den kritischen Daten sehe ich so:
Die Frage ist immer, wo steht die Datei und was ist an der anders als an der Scriptdatei selbst. Wenn sie für Außenstehende gleich schwer zu erreichen ist, dann ist kann man natürlich genau so auch Dein Perl-Script manipulieren. Speicherst Du sie an einem öffentlichen Ort, würde ich je nach Sicherheitsanforderungen, beim Einlesen etwas genauer prüfen. Prüfen - da wäre doch eine angehängte Prüfsumme (MD5 o.ä.) ganz nett. Jedenfalls würde es vor gröberen Manipulationen schützen.

Für strukturierte Daten nehme ich gern XML aber eigentlich nur, weil es ein gängiges Format ist.

Aber ich habe mal gelesen, daß @Strat auch mit Storable serialisierte Strukturen in eine Datenbank ablegt. Wenn man nur mit sich selbst kommuniziert, glaube ich, ist da die Scheißegalbedingung aktiv.

Ich benutze oft Storable, und wenn es wirklich menschenlesbar oder hochkompatibel sein muss, dann waehle ich Data::Dumper (in selteneren Faellen wegen der vielen Bugs YAML). Serialisierungsmodule haben den Vorteil, dass man auch komplizierte Strukturen einfach mit einem Funktionsaufruf laden/speichern kann.

Bei einer Abspeicherung in eine SQL-Datenbank muesste man erst einmal ein Schema erstellen und die Perldaten in dieses Schema pressen.

XML mag ich auch nicht, weil alle Moeglichkeiten unbefriedigend sind: die von XML::Dumper erzeugten Strukturen sehen umstaendlich aus, XML::Simple ist leider nicht mehr so simple, wenn die Strukturen komplizierter werden, und ein eigenere Parser/Writer aufwaendig zu schreiben. Oder kennt ihr bessere Moeglichkeiten?

die Kombination Data::Serializer und Storeable scheint nicht geschickt gewählt zu sein. Hatte das Ganze jetzt so angesetzt, dass ich Storeable, Blowfish und Sha256 benutzt habe, um die Daten verschlüsselt zu speichern. So weit zu gut. Wenn man jetzt aber versucht, die Daten mit einem falschen Schlüssel wieder zu laden, kam es bei mir immer zu harten Abstürzen, heißt einmal hat sich Storable beschwert, dass die Version nicht stimmen würde, dann konnte eine kurupte Zeichenfolge nicht als Object benutzt werden oder irgendwelche <--- HERE Document Fehler. Wenn man jedoch Data::Dumper scheint es - rein gefühlsmäßig - schneller zu sein und bei falschem Passwort nicht abzustürzen.
HTH

ist Config::General den ich benutze nicht auch eine art Serializer?

@esskar: ein eval drum rumpacken?

[quote=lichtkind,10.03.2005, 17:00]ist Config::General den ich benutze nicht auch eine art Serializer?[/quote]
Eine Art schon, aber ein echter Serializer kann viel mehr Perl-Datenstrukturen handhaben. Storable kann z.B. auch mit restricted keys/values in Hashes umgehen, oder CODE-Referenzen serialisieren.

[quote=Strat,10.03.2005, 17:05]@esskar: ein eval drum rumpacken?[/quote]
Ich kann mir gut vorstellen, dass es pathologische Faelle geben kann, bei denen Storable mit einem "Out of memory" abstuerzt. Da hilft auch ein eval nichts. Z.B., wenn ein String derialisiert werden soll, fuer den eine utopisch grosse Laenge vermerkt wurde.