Opened by der_thomas at 2013-10-13 11:26
User since
2006-07-10
2611 Artikel
BenutzerIn
2006-07-10
2611 Artikel
BenutzerIn
Um dir noch etwas zu denken zu geben. Perl kennt so schöne Sachen wie das "tie"-Iterface. und das Modul "orverload". Wenn es dir um wirklich einfache Verwenung geht dann schau dir das mal an.
Mit tie kannst du ein Objekt wie ein natives Array, Hash, Handle oder einen Scalar aussehen lassen.
Mit overvload kannst du native Operationen für Objekte definieren.
Dein Beispiel könnte so aussehen:
warum dann nicht beides? ...as_array, ...as_hash und ->set_value(...), ->get_value(...) Es ist halt immer die Frage wie viel Aufwand du betrieben willst. :-)
Du hast schon ein paar Probleme beim kompletten zurück schreiben erkannt. Es gibt noch mehr Probleme. Ein Array hat feste Folgen. Wenn sich dein Datenformat mal ändern sollte, musst du alle diesbezüglichen Programme umschreiben. Ich hab die Erfahrung schon mehrfach machen müssen. Man schreibt ein Programm und dann ändert sich eine Anbindung und ein Datenformat wird völlig auf den Kopf gestellt. Je höher die Abstraktion der Schnittstellen ist um so leichter verkraften sie tiefgreifende Veränderungen.
Um mal bei deinem Bücher Beispiel zu bleiben. Du entscheidest dich Nicht nur die Bücher zu speichern sondern auch die Biographien der Autoren zu den Büchern. Du kannst das mit einem Dutzend weiterer Spalten lösen in denen du viele Kopien der Biographien sicherst, oder du betrachtest alles von Anfang an als Objekte und brauchst später nur noch ein "Biographie-Objekt" zu ergänzen, das in der DB platzsparend über Referenzen verwaltet wird.
Und sei dir nicht sicher das immer nur wenige daten kopiert werden. Nicht nur die Anzahl der Felder bestimmt die Datengröße sondern auch was da drin steht. Stell dir vor du willst auch eine Zusammenfassung des Inhalts mit speichern, oder gar den Text des Buchs selber.
Oder ein andres Beispiel wo Kopien Probelmatisch sein können. Wenn du an mehreren stellen Änderungen an den Datensätzen vornimmst kann es dir passieren, dass du dir die eigenen Änderungen überschreibst weil du einmal vergessen hast die Daten aus der DB zu holen um dann im "Frontend"-Code die Änderungen zu machen und wider zurück zu schreiben. Stell dir vor du machst das "lesen-ändern-kopieren" an 100 Stelle und dann erkennst du einen Fehler darin. Du musst 100 Stellen korrigieren. Passiert eine grundlegende Prüfung im Backend brauchst du dir im Frontend darum keine Gedanken zu machen.
Mit tie kannst du ein Objekt wie ein natives Array, Hash, Handle oder einen Scalar aussehen lassen.
Mit overvload kannst du native Operationen für Objekte definieren.
Dein Beispiel könnte so aussehen:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9
tie(my @db, 'My::DB',$file); ... for my $temp (@db) { print "$temp->[1]\n"; } ... $db[100][1]="George Orwell";
QuoteIst zwar viel hin und her kopiererei, aber ich erspare mir damit die Überprüfung ob an den Textfeldern im Frontend was verändert wurde und könnte sehr leicht einen Schreibschutz implementieren.
warum dann nicht beides? ...as_array, ...as_hash und ->set_value(...), ->get_value(...) Es ist halt immer die Frage wie viel Aufwand du betrieben willst. :-)
Du hast schon ein paar Probleme beim kompletten zurück schreiben erkannt. Es gibt noch mehr Probleme. Ein Array hat feste Folgen. Wenn sich dein Datenformat mal ändern sollte, musst du alle diesbezüglichen Programme umschreiben. Ich hab die Erfahrung schon mehrfach machen müssen. Man schreibt ein Programm und dann ändert sich eine Anbindung und ein Datenformat wird völlig auf den Kopf gestellt. Je höher die Abstraktion der Schnittstellen ist um so leichter verkraften sie tiefgreifende Veränderungen.
Um mal bei deinem Bücher Beispiel zu bleiben. Du entscheidest dich Nicht nur die Bücher zu speichern sondern auch die Biographien der Autoren zu den Büchern. Du kannst das mit einem Dutzend weiterer Spalten lösen in denen du viele Kopien der Biographien sicherst, oder du betrachtest alles von Anfang an als Objekte und brauchst später nur noch ein "Biographie-Objekt" zu ergänzen, das in der DB platzsparend über Referenzen verwaltet wird.
Und sei dir nicht sicher das immer nur wenige daten kopiert werden. Nicht nur die Anzahl der Felder bestimmt die Datengröße sondern auch was da drin steht. Stell dir vor du willst auch eine Zusammenfassung des Inhalts mit speichern, oder gar den Text des Buchs selber.
Oder ein andres Beispiel wo Kopien Probelmatisch sein können. Wenn du an mehreren stellen Änderungen an den Datensätzen vornimmst kann es dir passieren, dass du dir die eigenen Änderungen überschreibst weil du einmal vergessen hast die Daten aus der DB zu holen um dann im "Frontend"-Code die Änderungen zu machen und wider zurück zu schreiben. Stell dir vor du machst das "lesen-ändern-kopieren" an 100 Stelle und dann erkennst du einen Fehler darin. Du musst 100 Stellen korrigieren. Passiert eine grundlegende Prüfung im Backend brauchst du dir im Frontend darum keine Gedanken zu machen.