Mini Datenbank (Projekte) - Perl-Community.de

[thread]18671[/thread]

Mini Datenbank

Leser: 27

Articles: hide open all | hide show old branches

+9 replies
der_thomas

2013-10-13 11:26

User since
2013-09-07
158 Artikel
BenutzerIn

Ich bräuchte bitte mal eure Meinung.

Es geht darum dass ich eine kleine Datenbank programmieren will. Umgesetzt habe ich das schon mit der anderen „P“ Sprache ...nicht PHP ;) - und das läuft auch alles wie gewollt und ist fast tagtäglich im Einsatz.
Eine Notwendigkeit besteht also nicht dass auch noch in Perl umzusetzen, aber ich lerne so einfach am besten....der Typ für Übungsaufgaben aus Büchern, Tutorials bin ich einfach nicht ;)
Zudem macht mir so etwas unheimlich viel Spaß, auch wenn die knappe Freizeit ein Hemmnis ist.

Das Ganze soll so frei sein dass man damit alles mögliche archivieren und bearbeiten kann, z.B. Bücherlisten, DVD Listen, Tagebuch, ToDo Listen u.s.w.....also im Prinzip alles was sonst auch recht gut per Calc oder Excel Liste machen könnte. Der Inhalt wird recht häufig geändert, ergänzt etc.)

Als Basis soll eine zweidimensionale Liste (Array) dienen.

Meine schon bestehende Version funktioniert folgendermaßen:
Ich habe ein Frontend inkl. GUI Klasse, die allerdings mit dem Datenarray direkt nichts zu tun hat, sondern....
....ein zweites Modul mit einer Datenklasse anspricht. Diese Klasse hat genau eine Instanz, nämlich das komplette zweidimensionale Array und wird von der Frontendklasse per Getter und Setter angesprochen.
Die Methoden dieser Datenklasse sind also beispielsweise „gib mir den ersten Datensatz“, „gib mir den nächsten Datensatz“, „sortiere die Daten nach Spalte x“, „speichere die Daten auf die Festplatte“, „markiere die Datensätze in denen das Wort xy vorkommt“ u.s.w.
Zurückgegeben wird bei den Gettern immer ein Datensatz in Form eines Arrays.
Per Setter zur Datenklasse geschickt wird z.B. ein veränderter oder neuer Datensatz – immer in Form eines Arrays.
Insgesamt sind es 25 Methoden die das gesamte Bearbeiten der zweidimensionalen Tabelle erledigen.
Dazu gehört auch das neue Anlegen einer Datenbanktabelle oder die Veränderung einer bestehenden Datenbanktabelle (hinzufügen, löschen oder sortieren der Spalten) - dafür soll es ein spezielles Frontend (Konsole) geben.
Wie gesagt, auf das zweidimensionale Array wird vom Frontend nie direkt zurückgegriffen.

Soweit ist das alles ok, ich fühle mich mit dieser Datenstruktur und Herangehensweise wohl und weiß (so einigermaßen :D) was da passiert.

Aber es gäbe natürlich Alternativen:
Die offenkundigste wäre wohl eine richtige Datenbank zu benutzen, will ich aber nicht da ich davon wenig Ahnung habe und es mir ums Erlernen von Perl geht.
Zum zweiten gibt es sicher auf CPAN schon was passendes, will ich auch nicht denn lernen würde ich auch da nicht viel.

Bleibt also nur was selbstgestricktes...was nebenbei auch wesentlich mehr Spaß macht :)

Was ich auf jeden Fall haben will ist eine Datenklasse in einem separaten Modul, dies deshalb um das für verschiedenste Datenbanken nutzen zu können (Die Frontends sollen sich nämlich unterschieden und müssen auch nicht immer GUI-Frontends sein).

Also Modul:
Version 1 wäre das oben beschriebene und von mir bereits umgesetzte.
Version 2 wäre wie Version 1, nur ohne OOP, also Modul mit Subroutinen.
Version 3 wäre jeden einzelnen Datensatz per einzelner Instanz darzustellen.

Die Performance spielt keine Rolle, es werden maximal Tabellen mit 400 Datensätzen und maximal 15 Spalten sein (die größte der bestehenden Datenbanken hat aktuell 165 Sätze mit je 13 Spalten), der Inhalt der Spalten ist nicht groß, maximal 50 Zeichen, in der Regel aber weniger als 20 und oft nur Boolean. Es muss nicht oder kaum gerechnet werden. Das Zeitaufwändigste wäre also das Sortieren der Daten was bei der Datenmenge nicht so tragisch sein sollte.

Wie in dem schon erstellten Programm will ich wieder so vorgehen dass das Frontend zuerst nur primitiv als Konsolenlösung umgesetzt wird, dies dient mehr oder weniger nur zum Testen des Datenmoduls. Und erst wenn das Datenmodul sicher funktioniert werden die jeweiligen Frontends umgesetzt.

Nun, nach tausend Worten meine Frage: Welche Version erscheint euch am sinnvollsten ?
Oder anders: Spräche was gegen Version 1 (die ich eigentlich sehr mag) ?
Gegen Version 3 spricht in meinen Augen dass das vermutlich schwer zu sortieren wäre bzw. ich die Instanzen doch wieder irgendwie per Index ansprechen müßte, also kaum was gewonnen wäre.

Falls es hilft, das Ganze besser zu verstehen kann ich auch gerne die Methoden(namen) des bereits bestehenden Programms hier zeigen - will diesen Post aber vorerst, ohne Not, nicht unnötig aufblähen ;)
- +8 replies
- rosti
  
  2013-10-13 12:08
  
  User since
  2011-03-19
  3472 Artikel
  BenutzerIn
  
  Die erste Frage sollte sein: Wie fest/lose soll der Data-Abstraktion Layer ans Programm gekoppelt sein?
  Feste Kopplung heißt u.a., dass sich zwischen DB-Design und Programm gewisse Abhängigkeiten ergeben, z.B. sind Feldnamen einer Tabelle im Programm gleichzeitig die Namen der Attribute in einer Objekt- oder Datenstruktur. Datentypen der DB-Engine werden konsequent genutzt und bestimmte Aufgaben erledigt die DB-Engine anstelle Programmcode.
  
  Heute morgen habe ich dieses Thema, was durchaus sehr komplex werden kann, in einem neuen kleinen Artikel umrissen:
  http://rolfrost.de/perlhash.html
  
  Da habe ich auch ein Beispiel für eine lose Kopplung, heißt, die DB-Engine ist nur zum Speichern da, keine Typisierung und im Programmcode keine SQL-Statements usw.
  
  Und sicher gibt es auch eine Reihe von CPAN-Modulen in dieser Richtung entwickelt. Du möchtest was Eigenes? Siehe Artikel. Eine eigene Klasse zum Entity-Attribute-Value Modell kriegst Du mit weniger als 100 Zeilen Perl-Code hin ;)
  
  --Rosti
  - pq
    
    2013-10-13 14:20
    
    User since
    2003-08-04
    12208 Artikel
    Admin1
    
    2013-10-13T10:08:59 rosti
    http://rolfrost.de/perlhash.html
    
    Quote
    Die Inkompatibilitäten des im Perl-Core eingebauten Serializers Storable und auch DB_File, brachte mich dazu, Serializer zu entwickeln, die plattformunabhängig und darüber hinaus versionsunabhängig sind.
    
    Ich würde eher schreiben, Storable wird als Core-Modul mitgeliefert. im Core eingebaut klingt so nach builtin-Funktion.
    
    Ich vermisse noch eine Erklärung, warum Storable inkompatibel sein soll (mit was?). Das klingt für mich so, als ob du nstore() nicht kennst.
    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
    lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +6 replies
  - der_thomas
    
    2013-10-13 17:42
    User since
    2013-09-07
    158 Artikel
    BenutzerIn
    
    Die Bindung der Datenbankklasse an das Frontend soll so lose wie nur möglich sein.
    Die zugrunde liegende Idee ist die, dass diese ganzen 2D-Array-Operationen im Grunde immer die gleichen sind, egal um was für Daten es sich handelt.
    z.B. „Neuen Datensatz anfügen“, "Datensatz (der im Frontend verändert wurde) wieder in die DB einbauen“ u.s.w.
    Die Methoden der Datenbankklasse sollen so allgemein sein dass sie mit jeglichen Daten auskommen, d.h. Egal ob z.B. die Spalte Nr.3 Strings oder Int´s beinhaltet.
    Und wenn hier ein Typ zwingend erforderlich ist, so 'kümmert' sich darum das Frontend.
    
    Sollte es wirklich vorkommen dass mit dem Inhalt Berechnungen durchgeführt werden müssen, würde das im Frontend oder noch besser in einer spezialisierten Unterklasse der Datenbankklasse geschehen.
    
    Mal als Beispiel eine vereinfachte Bücherliste:
    Spalte 1 = Titel
    Spalte 2 = Autor
    
    Die Verbindung zwischen Frontend und Datenbankklasse wäre nur ein temporär genutztes eindimensionales Array a´la „1984“, „Orwell“.
    Also z.B.
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12
    
    # Pseudocode des Frontends # aktueller Datensatz in der db-Klasse = der Datensatz der vor "1984", "Orwell" in der Matrix steht. @temp = db->get_next_row(); print $temp[1]; >>> Orwell $temp[1] = „George Orwell“; db->set_row(@temp); db->get_next_row(); #zum Test ein Sprung nach vorne in der db db->get_previous_row(); # und wieder zurück zum '1984' Datensatz print $temp[1]; >>> George Orwell
    
    Ein Frontend, das ich bei meinem bestehenden (Python)Programm nutze, kann beispielsweise gar keine Daten auf dem Bildschirm anzeigen, sondern erstellt nur geordnete *.txt Dateien in denen nur ein Teil der Spalten enthalten ist - auch hier ist dies aber nur das Frontend, die ganze Organisation des 2D Array´s übernimmt diese eine db-Klasse.
    Last edited: 2013-10-13 17:45:02 +0200 (CEST)
    - +5 replies
    - topeg
      
      2013-10-13 19:33
      
      User since
      2006-07-10
      2611 Artikel
      BenutzerIn
      
      Es gibt ein paar Gründe für und gegen ein Interface, also eine klar definierte Schnittstelle zwischen zwei Programmteilen oder Programmen.
      
      Ein Vorteil ist die Wiederverwendbarkeit. Ein einmal nach dem Interface geschriebener Code kann immer wieder an verschiedenen Stellen neu eingesetzt werden.
      Dann die Reimplementierbarkeit. Der Code hinter einem Interface kann ausgetauscht werden, ohne die restliche Applikation verändern zu müssen.
      Die Dokumentierbarkeit ist auch ein Vorteil. Eine Definiere Schnittstelle erklärt auch die Funktion eines Codeabschnitts.
      
      Dagegen spricht das Interfacecode komplexer sein muss als nötig um seine Aufgabe zu erfüllen. So müssen übergebene Parameter geprüft werden, oder Funktionen für Eventualitäten bereit gestellt werden, die dort wo der Code eingesetzt wird niemals auftauchen werden.
      Schnittstellen beschränken die Handlungsfreiheit des Programmierers und können dadurch zu schlechterem Code führen.
      
      Um dein Codebeispiel heran zu ziehen. Es kann nötig sein nicht nicht nur immer eine Spalte weiter zu springen sondern auch gezielt eine Spalte an zuspringen, oder Spalten zu vergleichen, darin zu suchen, bestimmte Spalten zu löschen oder weitere einzufügen. Es hängt sehr von deinem Interface-Design ab wie sinnvoll deine "db" Anbindung funktioniert. Dein Interface hängt sehr am Konzept des Arrays, obwohl es dich eigentlich nicht interessiert, ob du es mit einem Array zu tun hast oder einer anderen Datenstruktur.
      Du willst organisiert auf Daten zugreifen und dabei sollen die Daten nach bestimmten Kriterien organisiert sein. Eines dieser Kriterien soll die Gruppierung zu Datensätzen sein. Dabei sollen sie bestimmte Eigenschaften repräsentieren. Einer solcher Datensätze bildet also ein "Objekt" das ein bestimmtes Format aufweist das man als "Klasse" zusammen fassen kann. Viele dieser Objekte sind in einer eindeutigen Folge angeordnet und lassen sich darüber gezielt ansprechen. Aber ist diese Anordnung tatsächlich die beste Möglichkeit die Daten zu strukturieren? Hier ist wieder die Frage was willst du mit den Daten machen? Soll primär darin nach bestimmten Kriterien gesucht werden? Sollen sie nur gelistet werden? Sollen sie sortierbar sein? Das entscheidet die Struktur des Interfaces.
      Du hast das schon mal programmiert und benutzt. Was hat dich daran gestört? Was fandest du Praktisch? Wo hast du dir gesagt "Zu dumm das ich das so programmieren muss." "Ob das auch eleganter geht?" "Ob das auch übersichtlicher geht?"
      
      An deinem Beispiel wie man es auch machen kann:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
      
      my %dbconf=( db_file => 'buecher.db', row_names => qw(Autor Titel Jahr Seiten), auto_update => 0, ); my $db = db->new(%dbconf); if(my $elm=$db->get_first_eq('Autor','Orwell')) { $elm->set('Autor','George Orwell'), $db->update(); } for my $elm ($db->get_all_regexp('Autor',qr/georg/i)) { print join( ',', $elm->get('Titel','Jahr','Autor') )."\n"; } my $first=$db->get_by_pos(100); die("Zeile 100 existiert nicht!") unless defined $first; print $first->get('Titel')."\n"; my $next=$elm; while( $next = $next->next() ){ if( ! $next->equal($elm) ) { print $next->get('Titel')."\n"; } }
      
      Hier habe ich Wert auf ein einfaches und möglichst selbst erklärendes Interface gelegt. Man kann aus den Namensgebungen schon schließen was im Code passiert. Nachteil ist natürlich das viel im Code des db-Objekts gemacht werden muss. Wie du die Daten intern organisierst ist nicht wichtig, ob als "Array of Arrays" oder als "Array of Hashes" oder als "Array of Objects" oder anderes. Durch das recht hoch abstrahiere Interface kannst du alles dahinter nach gut dünken implementieren, oder auch verschiedenen Varianten um bestimmte Zugriffe zu beschleunigen. Aber diese hohe Abstraktion geht auf Kosten der Leistungsfähigkeit. Hinter dem Interace muss einiges gemacht werden, um die Befehle sinnvoll umzusetzen.
      - +4 replies
      - der_thomas
        
        2013-10-13 21:49
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Quote
        Ein Vorteil ist die Wiederverwendbarkeit. Ein einmal nach dem Interface geschriebener Code kann immer wieder an verschiedenen Stellen neu eingesetzt werden.
        Dann die Reimplementierbarkeit. Der Code hinter einem Interface kann ausgetauscht werden, ohne die restliche Applikation verändern zu müssen.
        Die Dokumentierbarkeit ist auch ein Vorteil. Eine Definiere Schnittstelle erklärt auch die Funktion eines Codeabschnitts.
        
        Dagegen spricht das Interfacecode komplexer sein muss als nötig um seine Aufgabe zu erfüllen. So müssen übergebene Parameter geprüft werden, oder Funktionen für Eventualitäten bereit gestellt werden, die dort wo der Code eingesetzt wird niemals auftauchen werden.
        Schnittstellen beschränken die Handlungsfreiheit des Programmierers und können dadurch zu schlechterem Code führen.
        
        Sehe ich ganz genauso...
        
        Quote
        Du hast das schon mal programmiert und benutzt. Was hat dich daran gestört? Was fandest du Praktisch? Wo hast du dir gesagt "Zu dumm das ich das so programmieren muss." "Ob das auch eleganter geht?" "Ob das auch übersichtlicher geht?"
        
        Ehrlich gesagt bin ich mit den bisherigen Methoden vollauf zufrieden, wobei die nicht auf einmal entstanden. Nach dem das Grundgerüst stand, machte ich das Frontend und entdeckte da natürlich schon noch einige Methoden die ich bräuchte oder gerne hätte und dementsprechend nachprogrammiert habe.
        Auch versuchte ich die Methoden so allgemein und flexibel zu halten um die Klasse für verschiedenste Dinge einsetzen zu können.
        
        Auch wenn das alles steht und die Umsetzung in Perl einfacher sein wird als am Original (müßte es im Grunde ja nur übersetzen) ist es dennoch mit Aufwand verbunden.
        Daher meine Frage nach der Meinung anderer, ob das generell so 'vernünftig' ist, oder ob es sinnvoller wäre die einzelnen Datensätze (Zeilen) zu je einem Objekt zu machen.
        Aber wenn ich dich richtig verstehe spricht kaum was gegen meine Vorgehensweise, solange ich damit klarkomme bzw. die Methoden flexibel genug sind um alle Eventualitäten abzudecken.
        
        Danke für das Codebeispiel, ist auf jeden Fall eine interessante Alternative.
        
        +3 replies
        
        topeg
        
        2013-10-13 23:11
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Wenn du für dich programmierst, dann mache es so wie du es für das beste hältst.
        
        Sollen auch andere mal damit arbeiten, dann trete ein Schritt zurück und vergiss alles was du über den Code weißt und versuche die Funktionsweise des nachzuvollziehen.
        
        Um mal konkret auf das Beispiel von dir einzugehen:
        
        Quote
        
        Code (perl): (dl )
        
        1 2 3
        
        @temp = db->get_next_row(); $temp[1] = "George Orwell"; db->set_row(@temp);
        
        Wenn ich das allein Betrachte kommen ein paar Fragen auf. Was steht in der Spalte "1"? Ist es der Autor, oder der Coautor, oder wem es gewidmet ist, oder einfach nur ein Name? Was passiert wenn das Array zu lang oder zu kurz ist? Warum werden alle Daten gelesen und wieder Zurück kopiert? Gibt es keine Funktion die Werte "Am Ort" verändert?
        Wäre so etwas nicht einfacher?
        
        Code (perl): (dl )
        
        1 2
        
        db->next_row(); db->set_value(1 => "George Orwell");
        
        Was mache ich wenn ich eine DB in eine andere kopieren will, oder eine mit mehreren anderen Ergänzen will? Muss ich erst alle lesen und dann in die Finale schreiben? Ein Paket (Klasse) zu benutzen macht die Verwendung bei einer Db einfacher, aber sobald es mehrere werden wird es kompliziert.
        
        Das meine ich mit einen Schritt zurück treten. Versuche dir vorzustellen was andere mit deinem Modul machen würden, was ihre Schwierigkeiten sein könnten.
        
        +2 replies
        
        der_thomas
        
        2013-10-14 21:52
        
        User since
        2013-09-07
        158 Artikel
        BenutzerIn
        
        Quote
        Wenn ich das allein Betrachte kommen ein paar Fragen auf...
        
        Du hast recht, aus der Sicht anderer wird’s natürlich schwer, andererseits ist es wohl immer ein Spagat zwischen einfacher Anwendbarkeit und Flexibilität.
        Als Extrembeispiel könnte ich eine Methode 'set_new_Autor' einführen, wäre klasse – aber eben nur in einer Bücherdatenbank ;)
        Ich umging das ein wenig indem ich im Frontend Konstanten einführte, also zum Beispiel
        AUTOR = 1 und temp[AUTOR] = „George“.
        Letztendlich muss man wohl abwägen was einem wichtiger ist, eine superkomfortable Bedienung der Datenbankklasse bei der Programmierung des Frontends oder ein Maximum an Flexibilität.
        
        Quote
        ...Warum werden alle Daten gelesen und wieder Zurück kopiert? Gibt es keine Funktion die Werte "Am Ort" verändert?...
        
        Praktisch sieht es derzeit in meinem Programm so aus dass wenn ein Datensatz ausgegeben werden soll:
        Dieser per temp = db.get_next_row() angefordert wird, als temp[] angekommen wird er auf die verschiedenen Textfelder der GUI Oberfläche verteilt.
        Springt man nun zum nächsten Datensatz (im Frontend) werden zuerst die Inhalte aller Textfelder ausgelesen in die temp[] gepackt, der Datenbankklasse per db.set_new_content_in_row(temp)
        zurückgeschickt, dort in die Tabelle reinkopiert und anschließend erfolgt der nächste
        temp = db.get_next_row() ...und das Ganze beginnt von vorne...
        Ist 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.
        Elegant ist daran allenfalls dass es einfach ist und die Datenwege simpel und leicht prüfbar sind.
        
        Hätten die Datensätze 100 oder mehr Spalten (Einträge pro Datensatz) bekäme ich hier sicherlich ein massives Performanceproblem, aber wie gesagt mehr als 15 Spalten werde ich kaum benötigen.
        
        Quote
        Was mache ich wenn ich eine DB in eine andere kopieren will, oder eine mit mehreren anderen Ergänzen will? Muss ich erst alle lesen und dann in die Finale schreiben? Ein Paket (Klasse) zu benutzen macht die Verwendung bei einer Db einfacher, aber sobald es mehrere werden wird es kompliziert.
        
        Das ist zugegebenermaßen bisher weder vorgesehen noch mit den bisher vorhandenen Methoden umsetzbar - um ehrlich zu sein, daran dachte ich nicht mal ;)
        Spontan würde ich es wohl recht hemdsärmlig lösen indem ich die Inhalte zweier Datenbanken mit einen 10 Zeiler Wegwerfcode zusammenfüge :)
        
        Ich werde erst mal einen Schritt zurückmachen und das nochmal überdenken, zeitlich könnte ich das eh erst in drei Wochen in Angriff nehmen.
        Danke für Deine Ausführungen, hilft mir sehr das Ganze mal aus einem anderen Blickwinkel zu betrachten.
        
        topeg
        
        2013-10-15 01:57
        
        User since
        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:
        
        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";
        
        Quote
        Ist 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.

View all threads created 2013-10-13 11:26.