Opened by Sven_123 at 2011-09-30 11:50
User since
2011-03-19
3271 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
2011-03-19
3271 Artikel
BenutzerIn
Hi,
mein Gedanke, der dahinter steckt, was die Datenhaltung betrifft:
Die kann in einer DB erfolgen oder in Dateien. Die Klasse zur Datenanbindung ist ein Abstraction-Layer (AL). Der Anwendung (App) ist es "egal", wo die Daten herkommen und wo die gespeichert werden. In der App wird nicht mit Dateihandler oder SQL-Statements 'rumgemacht, sondern da werden nur Methoden aufgerufen, welche die Datenstrukturen aus dem AL holen und dorthin zurückschreiben.
Sofern in der App immer die gleichen Datenstukturen vorliegen, gäbe es darüber hinaus auch die Möglichkeit mit Tie zu arbeiten, z.B. um einen Hash oder ein Array an eine Datei oder eine DB zu binden.
In der App hast Du dann den Kopf frei für das Wesentliche, z.B. Deine Berechnungen.
Interessante Frage: Wann Datei, wann DB? Betrachte die Performance, es braucht eine gewisse Zeit, den Connect zur DB herzustellen. Im Beispiel wäre es schneller, 20T Einträge aus einer Datei zu lesen, als die Verbindung zur DB herzustellen. I.d.R. wird bei einer Dateianbindung jedoch immer die gesamte Datenmenge in den RAM gelesen. Bei einer DB-Anbindung hingegen, hast Du nur die Ergebnismenge im RAM (was die DB-Engine an RAM verbraucht ist meistens weniger interessant).
Liegen jedoch 200T Messerte vor und es wird nur das Messergebnis von einem Tag gebraucht, ist die DB-Anbindung besser, vorausgesetzt, die Abfrage ist optimiert und der Index sitzt an der richtigen Stelle (hier das Datum).
Das ist also von Fall zu Fall abzuwägen und DB-Abfragen zu optimieren ist auch keine Hexerei ;)
Nochwas zum Thema, Hashes und Arrays. Beispielsweise liefert der AL ein Objekt, in welchem sowohl Hashes als auch Arrays drin sind. Zum Verbessern der Lesbarkeit in der App, werden einfach die Referenzen kopiert über Methodenaufrufe:
... so in Etwa...
--Rolf
mein Gedanke, der dahinter steckt, was die Datenhaltung betrifft:
Die kann in einer DB erfolgen oder in Dateien. Die Klasse zur Datenanbindung ist ein Abstraction-Layer (AL). Der Anwendung (App) ist es "egal", wo die Daten herkommen und wo die gespeichert werden. In der App wird nicht mit Dateihandler oder SQL-Statements 'rumgemacht, sondern da werden nur Methoden aufgerufen, welche die Datenstrukturen aus dem AL holen und dorthin zurückschreiben.
Sofern in der App immer die gleichen Datenstukturen vorliegen, gäbe es darüber hinaus auch die Möglichkeit mit Tie zu arbeiten, z.B. um einen Hash oder ein Array an eine Datei oder eine DB zu binden.
In der App hast Du dann den Kopf frei für das Wesentliche, z.B. Deine Berechnungen.
Interessante Frage: Wann Datei, wann DB? Betrachte die Performance, es braucht eine gewisse Zeit, den Connect zur DB herzustellen. Im Beispiel wäre es schneller, 20T Einträge aus einer Datei zu lesen, als die Verbindung zur DB herzustellen. I.d.R. wird bei einer Dateianbindung jedoch immer die gesamte Datenmenge in den RAM gelesen. Bei einer DB-Anbindung hingegen, hast Du nur die Ergebnismenge im RAM (was die DB-Engine an RAM verbraucht ist meistens weniger interessant).
Liegen jedoch 200T Messerte vor und es wird nur das Messergebnis von einem Tag gebraucht, ist die DB-Anbindung besser, vorausgesetzt, die Abfrage ist optimiert und der Index sitzt an der richtigen Stelle (hier das Datum).
Das ist also von Fall zu Fall abzuwägen und DB-Abfragen zu optimieren ist auch keine Hexerei ;)
Nochwas zum Thema, Hashes und Arrays. Beispielsweise liefert der AL ein Objekt, in welchem sowohl Hashes als auch Arrays drin sind. Zum Verbessern der Lesbarkeit in der App, werden einfach die Referenzen kopiert über Methodenaufrufe:
Code (perl): (dl
)
1 2 3
my $ob = Foo->new('2011-10-05'); # alles drin für einen Tag my $array_ref = $o->show_temperaturen; my $hash_ref = $o->show_messpunkte;
... so in Etwa...
--Rolf