nicht angemeldet
Lineare Datenbanken
Struppihi,
Perler, wo seid Ihr!? Macht Ihr eigentlich noch was mit DB_File? Malsogefragt...
Also, ich hab das Modul im Einsatz für meinen Mondkalender, DB_File greift da auf ein Dateichen mit über 20.000 Mondphasen von 1700 bis 2199. Die Datei hat eine Größe von ca 600 kB. Die Datenhaltung ist total einfach: Das Datum ist der Key und die Values sind First, Last, Full und New.
Ne Zeitlang hatte ich diese Daten in einer MySQL-Tabelle, aber DB_File ist ganz einfach performanter, DB_File wird an einen hash gebunden und schnapp sind die Values greifbar. Btw., ich hab die komplette WebSite per Rewrite auf DB_File umgeschossen, das bringt so einige Vereinfachungen mit sich, auch bezüglich Content-Management. Die content.db hat derzeit eine Größe von 2 MB.
In Summa ist DB_File eine interesante Alternative zu MySQL, wenn mehrere Spalten gebraucht werden, gibt es auch verschiedene Möglichkeiten dazu:
- je Spalte eine Datei (name.db, vname.db, ...),
- Spaltentrenner im Value (name|vname|plz|ort ...),
- Zellenadressierung im Key nach dem Schema "row#.col#" (1.1, 1.2 usw.).
Schreibt mal wieder ;-)
Hotte
--
Hottentotten sind niedlich.
Hottentotten sind niedlich.
-
Perler, wo seid Ihr!? Macht Ihr eigentlich noch was mit DB_File?
Habe ich noch nie benutzt.
Auf meinem Paket (das ich vor neuen Jehren erwarb) war kein MySQL dabei.
Ich habe damit angefangen mein eigenes DB Format zu entwickeln, und verwende jetzt zwei Versionen.Version 1 beruht auf Flat Files und ist für mehrere MB grosse Files geeignet.
Es ist nicht erforderlich, dass die Daten vollständig oder in einer definierten Reihenfolge gespeichert sind, denn der Feldname wird immer mitgespeichert. Das macht diese Files sehr flexibel.
ausgelesen wird mit Tie::File
Flat Files in diesem Format geben mir den Vorteil, dass ich keinerlei Beschränkung habe in der Komplexität der Abfrage.In Version 2 setze ich auf das Modul Storabel und speichere direkt komplexe Datenstrukturen. Das eignet sich für Daten de für ein Programm immer notwendig sind. Nachteil ist, dass ich einen speziellen import/export schreiben muss.
File-Locking Mechanismen haben beide Versionen über die Jahre in einem gesunden Zustand belassen.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Moin Beat,
ausgelesen wird mit Tie::File
das werde ich mir mal anschauen, danke Dir!
Viele Grüße,
Horst Haselhuhn--
Tie a yellow ribbon 'round the old oak tree... Done.-
ausgelesen wird mit Tie::File
das werde ich mir mal anschauen, danke Dir!Keine Wunder erwarten.
Tie::File bietet dir nur den Luxus RAM und CPU sparender Iteration über grosse Files. Du hast immer gleichzeitig read/write Zugriff während der Iteration.
Umgewöhnen musst du dich bei der Default Behandlung von "\n".
Tie::File entfernt "\n", wenn es der Zeilen(=Array-Element)-Separator ist,
fügt ihn aber vor dem Speichern wieder hinzu,
wobei beide Zuweisungen
$_ = "neue Daten";
und
$_ = "neue Daten\n";
zum gleichen Ergebnis führen.
Daten werden gelöscht durch
$_=""
was aber nun eine leere Zeile im File hinterlässt.
Damit sich diese nicht aufkumulieren, tätige ich am Ende von kleinen Files
@file = grep /^./, @file
Bei grösseren Files verwende ich einen klügeren Mechanismus, der splice sparsam anwendet. (splice von hinten aufrollen)mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
moin,
Keine Wunder erwarten.
Tie::File bietet dir nur den Luxus RAM und CPU sparender Iteration über grosse Files. Du hast immer gleichzeitig read/write Zugriff während der Iteration.Yepp. Im Prinzip dasselbe, was DB_File.pm mit DB_RECNO auch macht.
DB_RECNO provides an interface to flat text files. Both variable and fixed length records are supported.
Damit hab ich schon gearbeitet ;-)
Hotte
-
-
-
-
Perler, wo seid Ihr!? Macht Ihr eigentlich noch was mit DB_File? Malsogefragt...
Ja, aber ich bin vorsichtig geworden.
http://perldoc.perl.org/DB_File.html#Using-DB_File-with-Berkeley-DB-version-2-or-greaterBeim letzten Update hatte sich gleichzeitig ein Modul zum lesen von MP3 Tags, grundlegend geändert, das war ziemlich nervig und hat mein Mißtrauen gegenüber CPAN Module erhöht.
Struppi.
-
Perler, wo seid Ihr!? Macht Ihr eigentlich noch was mit DB_File? Malsogefragt...
Ja, aber ich bin vorsichtig geworden.
http://perldoc.perl.org/DB_File.html#Using-DB_File-with-Berkeley-DB-version-2-or-greaterBeim letzten Update hatte sich gleichzeitig ein Modul zum lesen von MP3 Tags, grundlegend geändert, das war ziemlich nervig und hat mein Mißtrauen gegenüber CPAN Module erhöht.
CPAN ist ein Sammelbegriff für eine abfragbare weltweite Library. Kein Produktestandard.
Wenn ich etwas über die Qualität von Modulen wissen will, google ich nach Anwendungen, die es verwenden, oder nach Buglisten. Fehlt all dies, so weiss ich, dass das Modul nichts wert ist.Bsp: Das Modul Win32::Midi hat eine so lausige Dokumentation und sehr wenig Anwendungsnachweis, dass es mich nicht wundert, dass ich in der Anwendung dieses Moduls bisher gescheitert bin. Weil dann andere Teile des Moduls als dll Datei eingebunden werden, habe ich nicht mal die Chance, den Mangel in der Dokumentation zu ergänzen.
Seien wir ehrlich. Perl ist in die Jahre gekommen, und man merkt es ihm an.
Es gibt nicht mehr die grosse Community, welche den ganzen Bestand pflegt.Ich werde mir wohl einen Umstieg auf Python überlegen müssen, wenn ich meine Soundkarte erfolgreich ansprechen will. Mit Perl habe ich es bisher nicht geschafft.
mfg Beat
-
Mahlzeit;
Perler, wo seid Ihr!? Macht Ihr eigentlich noch was mit DB_File? Malsogefragt...
Ja, aber ich bin vorsichtig geworden.
http://perldoc.perl.org/DB_File.html#Using-DB_File-with-Berkeley-DB-version-2-or-greaterJa, Struppi, es gab schon immer Probleme mit der Portierbarkeit der DB-Dateien auf andere OS'sse. Bei meinem Provider hab ich jedoch gesehen und getestet, dass meine auf XP mit DB_File erstellten Dateien auch auf dem Server (OS linuxartig) funktionieren und da hab ich eben sofort "was draus gemacht", auch begünstigt dadurch, dass mein Provider den Webserver mit Suexec am Laufen hat (damit entfällt das Gefummel mit den Berechtigungen). Hinzu kommt, dass der MySQL-Server nicht auf derselben Kiste läuft wie der Apache, der ist auf einer extra dedizierten Machine aufgesetzt und zwischendrin ist eine Firewall, die von einer Fremdfirma betreut wird. Bandbreitenmäßig ist diese Anbindung nicht allzu rosig und wg. der FW gabs da auch schonmal Probleme....
Hotte
-
Ja, aber ich bin vorsichtig geworden.
http://perldoc.perl.org/DB_File.html#Using-DB_File-with-Berkeley-DB-version-2-or-greaterJa, Struppi, es gab schon immer Probleme mit der Portierbarkeit der DB-Dateien auf andere OS'sse.
... darum geht es gar nicht in dem Abschnitt, den ich dir verlinkt habe. Es geht um die Portierbarkeit der verschiedenen Versionen. Ich hatte nach einem Perl-update keinen Zugriff mehr auf meine DB_File Daten, was u.U. eine Katastrofe bedeuten kann (in dem Fall war es noch erträglich, da nur eine kleinere Spielerei).
Struppi.
-
Ja, aber ich bin vorsichtig geworden.
http://perldoc.perl.org/DB_File.html#Using-DB_File-with-Berkeley-DB-version-2-or-greaterJa, Struppi, es gab schon immer Probleme mit der Portierbarkeit der DB-Dateien auf andere OS'sse.
... darum geht es gar nicht in dem Abschnitt, den ich dir verlinkt habe. Es geht um die Portierbarkeit der verschiedenen Versionen. [..]
Jaja, schon klar ;-)
Hotte
-
-
-