Schrift
[thread]11135[/thread]

„MySQL: Wie funktioniert UPDATE“ und „INSERT“ mit Perl (Seite 2)

Leser: 25


<< |< 1 2 3 >| >> 21 Einträge, 3 Seiten
Gast Gast
 2010-02-05 17:52
#131878 #131878
Ihr seit ja schnell. :-)

Das Tutorial auf, perloo.de/DBI/ kenne ich und auch den Stil im Perl Kochbuch.
Meine Sql Befehle mit DBI führe ich ähnlich wie der Threadstarter aus.

Jetzt suche ich eine Möglichkeit, meine Abfragen Halbwegs Perfekt zu gestalten.
Habe hier schon das halbe Forum durch gesucht und wollte jetzt einfach nur mal Fragen wie Ihr das so General macht?

Danke erstmal für die Vorschläge, werde ich gleich mal testen. :-)
renee
 2010-02-05 18:01
#131879 #131879
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Was verstehst Du unter "perfekt"?
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
GwenDragon
 2010-02-05 18:02
#131880 #131880
User since
2005-01-17
14848 Artikel
Admin1
[Homepage]
user image
Es gibt keine perfekten Abfragen.

Was du beachten musst, haben wir dir ja schon gesagt.
Mein Tipp:

* Verwende use strict; und use warnings;
* Verwende bei Abfragen Platzhalter, das verhindert SQL-Injections
* Schließe möglichst früh wieder das Datenbankhandle, wenn du es nicht brauchst, das kann Resourcen sparen
* Wenn du Abfragen machst, begrenze sie, dass du nicht alle Daten abholst, nicht alles in den Hauptspeicher (Array ist hier gemeint), sonst läuft dir bei großen Datenmengen der Haupspeicher zu und das System muss auslagern (macht langsam)
* Überprüfe selbst, ob die Datenbankabfragen geklappt haben mit or die DBI::errstr;, dann erscheinen sie nicht in deinen Ausgaben

//EDIT: Ansonsten ist Perl immer Lerning by Doing und TIMTOWDI (There Is More Than One Way To Do It.).
Last edited: 2010-02-05 18:05:12 +0100 (CET)
pq
 2010-02-05 18:07
#131885 #131885
User since
2003-08-04
12209 Artikel
Admin1
[Homepage]
user image
ein paar links dazu:
2010-02-05T17:02:10 GwenDragon
* Verwende use strict; und use warnings;

Wiki:use strict

Quote
* Verwende bei Abfragen Platzhalter, das verhindert SQL-Injections

Wiki:DbiPlatzhalter
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: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
sid burn
 2010-02-05 18:25
#131892 #131892
User since
2006-03-29
1520 Artikel
BenutzerIn

user image
Quote
* Schließe möglichst früh wieder das Datenbankhandle, wenn du es nicht brauchst, das kann Resourcen sparen

Wobei der Tipp vom der Umgebung abhängt. In einer Persistenten Umgebung wäre das für mich zumindest eher ein schlechter Tipp.

Quote
* Überprüfe selbst, ob die Datenbankabfragen geklappt haben mit or die DBI::errstr;, dann erscheinen sie nicht in deinen Ausgaben

Hier lautet mein Tipp eher "RaiseError => 1" bei den DBI Optionen zu übergeben, dann wirft DBI bei Problemen selber Fehler, man kann es nicht vergessen, und es ist weniger Tipparbeit.
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
GwenDragon
 2010-02-05 18:32
#131894 #131894
User since
2005-01-17
14848 Artikel
Admin1
[Homepage]
user image
2010-02-05T17:25:24 sid burn
Quote
* Schließe möglichst früh wieder das Datenbankhandle, wenn du es nicht brauchst, das kann Resourcen sparen

Wobei der Tipp vom der Umgebung abhängt. In einer Persistenten Umgebung wäre das für mich zumindest eher ein schlechter Tipp.
Oh, ja.
Ich dachte an die meist übliche Verwendung unter CGI (ohne mod_perl & Co.)

Es kommt wohl drauf an wieviele Leute am SQL-Server hängen. Da kann es schon mal zu viele Connects geben. Oder täusche ich mich bei den heutigen MySQL-Servern?

Quote
Quote
* Überprüfe selbst, ob die Datenbankabfragen geklappt haben mit or die DBI::errstr;, dann erscheinen sie nicht in deinen Ausgaben

Hier lautet mein Tipp eher "RaiseError => 1" bei den DBI Optionen zu übergeben, dann wirft DBI bei Problemen selber Fehler, man kann es nicht vergessen, und es ist weniger Tipparbeit.
Teilweise gebe ich dir Recht.
Es kommt immer drauf an, ob die Meldungen nur zur Analyse verwendet werden, das Programm beenden zu lassen bei Problemen gewünscht ist oder selbst eine verständliche Meldung ausgeben werden soll.
Kommt eben auf die Benutzeroberfläche an, welche Datenbank abfragt bzw. durch diese mit Daten versorgt wird.
sid burn
 2010-02-05 18:56
#131899 #131899
User since
2006-03-29
1520 Artikel
BenutzerIn

user image
Quote
Es kommt wohl drauf an wieviele Leute am SQL-Server hängen. Da kann es schon mal zu viele Connects geben. Oder täusche ich mich bei den heutigen MySQL-Servern?

Das hängt wohl lediglich von den Einstellungen ab.

Quote
Teilweise gebe ich dir Recht. Es kommt immer drauf an, ob die Meldungen nur zur Analyse verwendet werden, das Programm beenden zu lassen bei Problemen gewünscht ist oder selbst eine verständliche Meldung ausgeben werden soll.

Ist alles kein Grund keine Exceptions zu verwenden. RaiseError ist dafür da das automatisch bei Fehler ausnahmen wirft, anstatt das Fehler durch return codes zurück gegeben wird, die man auswerten muss, und es auch noch vergessen kann.

Möchte man explizit fehler zulassen so arbeitet man mit block "eval {}" oder eben Modulen wie Try::Tiny oder TryCatch um ausnahmen abzufangen. Und auch hier ist es von Vorteil wenn automatisch Exceptions geworfen werden. Da man so auch eine reihe von Befehlen abfangen kann.

Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
11
12
eval {
  $sth->prepare(...);
  $sth->execute(...);
  $sth->prepare(...);
  $sth->execute(...);
  $sth->prepare(...);
  $sth->execute(...);
};
if ( $@ ) {
  warn "Shit meine Logische einheit xyz zu machen ist fehlgeschlagen"
  # ... weitere fehlerbehanldung
}


Bei dir hingegen mischt du code mit fehlerbehandlung.

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
  $sth->prepare(...) or do {
    warn "Shit meine Logische einheit xyz zu machen ist fehlgeschlagen"
    # ... weitere fehlerbehanldung
  };
  $sth->execute(...) or do {
    warn "Shit meine Logische einheit xyz zu machen ist fehlgeschlagen"
    # ... weitere fehlerbehanldung
  };
  $sth->prepare(...) or do {
    warn "Shit meine Logische einheit xyz zu machen ist fehlgeschlagen"
    # ... weitere fehlerbehanldung
  };
  $sth->execute(...) or do {
    warn "Shit meine Logische einheit xyz zu machen ist fehlgeschlagen"
    # ... weitere fehlerbehanldung
  };
  $sth->prepare(...) or do {
    warn "Shit meine Logische einheit xyz zu machen ist fehlgeschlagen"
    # ... weitere fehlerbehanldung
  };
  $sth->execute(...) or do {
    warn "Shit meine Logische einheit xyz zu machen ist fehlgeschlagen"
    # ... weitere fehlerbehanldung
  };


Das ist unleserlicher, schwer nachzuvollziehen und viel zu viel Tipparbeit. Und du geht wie immer das risiko ein irgendwo eine abfrage mit "or do" etc. zu vergessen.

Ansonsten kannst du Den Fehler genauso auswerten wie ohne Exception. Der Fehler liegt weiterhin in $DBI::errstr oder besser ist man wertet dann $@ ab, wo der dann auch drin landet.

Quote
Kommt eben auf die Benutzeroberfläche an, welche Datenbank abfragt bzw. durch diese mit Daten versorgt wird.

All die Punkte sind komplett unwichtig. Fehler sollten grundsätzlich Exceptions werfen und über einen try{} catch{} Mechanismus abgefangen werden.

So macht es jede neue Programmiersprache und wird es auch Perl 6 machen. Es nicht so zu machen ist einfach Old School C Hackish.

Schau dir halt nochmal PBP an zum Thema Exceptions und Fehlerhandling.

Wenn du übrigens korrekte und vernünftige Exception Objekte wirfst ist das Fehlerhandling sogar leichter. Leider macht davon fast kein Modul von gebrauch. In der Hinsischt ist die Perl Community immer noch ein zurück gebliebenes Kind.
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
Gast Gast
 2010-02-05 19:00
#131900 #131900
Danke für die Tipps :-)
Habe jetzt meine Abfrage verändert und hoffe das ich Eure Tipps richtig umgesetzt habe?

//Vorher wie in diesem Beitrag beschrieben ...
Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
my $dbh = db_open();
my $id = ''; ## //Wird durch Param übergeben ...
my $sql = "SELECT id,name,text FROM test WHERE id=$id";
my $allref = $dbh->selectall_arrayref($sql, { Slice=>[] });
foreach my $test (@$allref) {
$htc->param(
homename => $test->[1],
home => $test->[2]
);
} $dbh->disconnect();

//Jetzt (angepasst)
Code (perl): (dl )
1
2
3
4
5
6
7
8
9
10
11
my $dbh = db_open();
my $id = ''; ## //Wird durch Param übergeben ...
my $stmt = q~SELECT id,name,text FROM test WHERE id=?~;
my $sth = $dbh->prepare( $stmt ) or die $dbh->errstr;
$sth->execute($id) or die $dbh->errstr;
while(my $row = $sth->fetchrow_hashref() ) {
$htc->param(
homename => $row->{'name'},
home => $row->{'text'}
);
} $dbh->disconnect();


## // Verbindung (angepasst)
Code (perl): (dl )
1
2
3
4
5
6
7
8
sub db_open {
my $db = 'test'; my $host = 'localhost';
my $user = 'test'; my $pw = '123456';
my $dsn = "DBI:mysql:database=$db;host=$host";
my $opt = { RaiseError => 1, AutoCommit => 1 };
my $dbh = DBI->connect($dsn, $user, $pw, $opt);
return $dbh;
}



Letzte Frage an die die Profis, ist das so OK?
Edit: Werde die anderen Beiträge auch noch mal durch arbeiten ...


Danke Euch :-)
Gast Gast
 2010-02-05 19:03
#131901 #131901
Edit: // Das or die $dbh->errstr; kann ja jetzt raus ...
pq
 2010-02-05 19:06
#131903 #131903
User since
2003-08-04
12209 Artikel
Admin1
[Homepage]
user image
gast: mit der schleife und dem aufruf von $htc->param überschreibst du die template-parameter jedesmal. in dem fall musst du die einzelnen rows in einem array speichern und param() nach der schleife aufrufen.
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: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
<< |< 1 2 3 >| >> 21 Einträge, 3 Seiten



View all threads created 2008-01-13 18:07.