PHP @mysql_query vs. mysql_query

[Überkinger]

hi, worin besteht der Unterschied zuwischen @mysql_query und mysql_query ?

 

[mercsen]

@ unterdrückt schlicht und einfach fehlermeldungen.....

http://de.php.net/manual/de/language.operators.errorcontrol.php

 

[felipermd]

...und ist wohl bei so einer Funktion nicht empfehlenswert! Das "@" alleine davor solltest du nur bei Funktionen verwenden, auf die es nicht besonders ankommt.

mysql_query() spricht dafür, dass irgendetwas aus der Datenbank geholt wird, was du auch brauchst. Wenn der Query nicht ausgeführt wird, wird auf der Seite wohl auch etwas nicht ordnungsgemäß funktionieren. Und wenn du dann ein @ davor machst, suchst du dich im Fehlerfall dusselig, weil die Funktion ja kein Fehleroutput gibt.

Günstiger ist es, eine Fehlerabfrage selber zu machen. Dann kannst du mit @ arbeiten. Sieht (etwa) so aus:

$sql = "SELECT * FROM `tabelle`;
$sqlr = @mysql_query($sql);
if ( !$sqlr ) { die("Fehler beim Ausführen von mysql_query()."); }
[...]

 

[mercsen]

also, mysql_query erzeugt nur einen fehler wenn man z.b. nicht mit der DB verbunden ist oder keine Datenbank ausgewählt hat. Das soltle man einfach schon vorher prüfen und anschließend dann sowas machen

$resource = mysql_query($sql);
if($resource) {
     // Alles ok
} else {
    // Nicht ok
}

so sieht man dann ob der eigentliche query erfolgreich war, oder aber ob die Datenbank ein leeres Ergebnis geliefert hat.

Bevor man mysql_query aber ausführt würde ich immer sicher gehen das alle verbindungen etc. stehen.
Und die() ist die denkbar schlechteste lösung

Alternativ kann man auch mysql_errorn() benutzen oder prüfen ob in $resource auch wirklich eine resource vorhanden ist.

 

[voodoo44]

Und die() ist die denkbar schlechteste lösung

Aus welchem Grund?
Es macht keinen Sinn ein Script auszuführen, welches z.B. als einzigen Zweck eine Auflistung der Daten in einer Datenbank und deren Weiterverarbeitung hat.
Ohne diese Daten kannst du mit dem Script nichts anstellen - warum sollte man das dann nicht mit einer kurzen Fehlermeldung beenden?!

 

[mercsen]

es gibt natürlichbereiche wo es sinn macht.
aber z.b. ist es durchaus sinnvoller den fehler genauer zu analysieren, statt schlicht zu sagen "Es geht nicht".

wenn der query dann z.b. aus einer SQL Klasse aus aufgerufen wird, beendet der die befehl auch alle nachfolgenden operationen.

Bei kleinen scripten mag es noch sinnvoll erscheinen, aber bei etwas komplexeren Aufgaben ist es absolut nicht zu empfehlen. Fehler sollte man grundsätzlich abfangen und behandeln und nicht einfach das komplette Script beenden.

 

[voodoo44]

Ähm ... genau das wurde im Beispielscript aber gemacht.
Fehler abgefragt und behandelt - mit einem die() darauf reagiert.

Was nützt es dir, die Webseite weiter aufzubauen, wenn du keine Daten hast, die du anzeigen kannst?
Ich kann herzlich viel "behandeln" - wenn aber der DBMS-Server meines Statistiktools down ist, bringt es mich nicht weiter, trotzdem alle Anzeigeelemente mit irgendwelchen Fantasiewerten oder schlichtweg "0" anzuzeigen.
Das erzeugt unnötigen Traffic, Serverlast und vergeudet beim Nutzer sinnlose Zeit.

 

[mercsen]

ja, aber sie meisten seiten sind schön strukturiert aufgebaut.
wennn du nicht gerade mit einem template system arbeitest wird dann die seite nur halb angezeigt oder aber statt deinem schönen designe eine einzige textzeile in der steht das es ein problem gab.
Die Serverlast zum ausgeben der restlichen Seite darf natürlich nicht unterschätzt werden, da hast du recht. Wer will schon 0,5 mikrosekunden prozessorzeit vergeuden!
Und wenn dein DB server down ist, dein script aber trotzdem bis zu dem query kommt würde ich mir mal gedanken über den aufbau machen!

 

[voodoo44]

Wer schreibt hier von "bis zum query kommen"?
Das war eine allgemeine Aussage, die du getroffen hast - die bezog sich nicht speziell auf die Programmarchitektur.

Nur weil ich das Beispiel mit dem DB-Server down gerade gebracht habe ...

Aber wo wir grad bei "Spezialfällen" sind:
- Script baut Verbindung zum Server auf
- Script schiebt Query zusammen
- DB-Server stürzt ab/ist nicht mehr erreichbar
- Script will Query abfeuern

Hat also überhaupt nichts mit der Programmarchitektur zu tun. Punkt 1 und 2 kannst du auch austauschen, wenn du willst.

Und die 0.5 Microsekunden Prozessorzeit - nun ... http://www.heise.de/tp/artikel/24/24720/1.html - das war 2007 ...
Rechne dir selbst aus, wieviele Suchanfragen 280 Millionen pro Tag umgerechnet in Stunden sind - und rechne dir einfach mal aus, auf was für eine Zahl du kommst, wenn du 1 Stunde lang für jeden Besucher 0.5 Mikrosekunden Rechenzeit einsparen könntest.

Wo wir aber grad bei Programmarchitektur wären:
Warum wird bei dir ein Template ausgegeben, bevor der Inhalt komplett erstellt wurde? Also bei mir fügt man den Inhalt am Ende des Programmes zusammen, wenn alle Inhalte abgerufen und verarbeitet wurden.

Aber das wird langsam recht OT.

Kurz zusammengefasst: Ein die() kann durchaus sinnvoll sein. Und dass ein aufgerufenes PHP-Script immer ein "Design" vorweisen muss halte ich für ein Gerücht.

Ich jedenfalls habe IMMER auf die die() Funktion gesetzt, wenn meine Implementierungen der OGC-Spezifikationen keine Datenbankverbindung bekommen haben. Wofür soll ich noch irgendwelche Dom-Dokumente zusammenschieben, wenn ich am Ende eh keine Daten habe?

 

[ice-breaker]

Und die 0.5 Microsekunden Prozessorzeit - nun ... http://www.heise.de/tp/artikel/24/24720/1.html - das war 2007 ...
Rechne dir selbst aus, wieviele Suchanfragen 280 Millionen pro Tag umgerechnet in Stunden sind - und rechne dir einfach mal aus, auf was für eine Zahl du kommst, wenn du 1 Stunde lang für jeden Besucher 0.5 Mikrosekunden Rechenzeit einsparen könntest.

Der Vergleich ist absolut lächerlich, wenn es bei dir auf 0.5 Mikrosekunden ankommt, dann hast du ganz andere Probleme und Anforderungen, PHP wird schonmal wegfallen, weil es im Vergleich zu anderen Sprachen zu langsam ist.

Ich jedenfalls habe IMMER auf die die() Funktion gesetzt, wenn meine Implementierungen der OGC-Spezifikationen keine Datenbankverbindung bekommen haben. Wofür soll ich noch irgendwelche Dom-Dokumente zusammenschieben, wenn ich am Ende eh keine Daten habe?

Weil du mit dem Ausgeben einer weißen Seite mit einer Meldung wie "DB-Connection failed" ganz schnell deine Besucher los bist!
Google, weil du es angesprochen hast, wird dir auch nicht einfach eine Fehlermeldung vor die Füße werfen, wenn eine Server abstürzt und der Request deswegen abbrechen muss, sondern wird dir eine Fehlerseite zeigen, es gehört zum guten Ton.
Und irgendwann tritt so ein Fehler immer mal auf.

 

[voodoo44]

Der Vergleich ist absolut lächerlich, wenn es bei dir auf 0.5 Mikrosekunden ankommt, dann hast du ganz andere Probleme und Anforderungen, PHP wird schonmal wegfallen, weil es im Vergleich zu anderen Sprachen zu langsam ist.

Mir sind 0.5 Mikrosekunden vollkommen egal - ich wollte damit lediglich aufzeigen, dass so etwas bei vielen Besuchern durchaus Sinn machen kann, das Script zu beenden.
Demnächst schreiben wir dann alle unsere Forensoftware in Assembler, oder?

Weil du mit dem Ausgeben einer weißen Seite mit einer Meldung wie "DB-Connection failed" ganz schnell deine Besucher los bist!

Als ob es (deshalb habe ich es auch extra im Beitrag erwähnt) einem Computer interessiert, ob er nun eine, mit CSS verschönerte, Fehlermeldung als XML bekommt oder ob er nur reinen XML-Code ohne CSS bekommt.

 

[ice-breaker]

Vor dem PC sitzt ein Mensch !

 

[Trainmaster]

Warum wird bei dir ein Template ausgegeben, bevor der Inhalt komplett erstellt wurde? Also bei mir fügt man den Inhalt am Ende des Programmes zusammen, wenn alle Inhalte abgerufen und verarbeitet wurden.

Ein Website besteht meist nicht zu 100 % aus dynamischen Inhalten. Zudem können Inhalte aus verschiedenen Datenbankquellen abgerufen werden. Selbst wenn es beim Zugriff auf diese Inhalte Probleme geben sollte, rechtfertigt es noch lange nicht, die Website nicht anzuzeigen. Vielmehr ist es im Sinne der Benutzerfreundlichkeit, dem Anwender eine wohlformatierte Fehlermeldung in der gewohnten Umgebung zurückzugeben.

 

[voodoo44]

Vor dem PC sitzt ein Mensch !

Erzähl das mal einem CSW, der gerade im Harvesting-Modus ist. Dem ist es egal, wie die Ausgabe formatiert ist - da ist die Syntax wichtiger ...

Vielmehr ist es im Sinne der Benutzerfreundlichkeit, dem Anwender eine wohlformatierte Fehlermeldung in der gewohnten Umgebung zurückzugeben.

Ein PC selbst schert sich nicht um irgendwelche Formatierungen oder Templates, wenn er Daten abruft - dafür interessiert sich nur ein Nutzer.

Davon abgesehen spricht sicher nichts dagegen, mit die(showError($errormessage)); ein Script zu beenden. Die Methode getContent könnte nämlich auch ein "Fehlertemplate" enthalten - dann müsste der User nicht irgendwelche Javascripts, die ansonsten mit der Webseite geladen werden, runterladen.
Was genau ist daran jetzt so verwerflich? Niemand schreibt hier davon, dass man dem User nicht trotzdem eine einfache Fehlerseite auswerfen könnte. Ebenso ist nicht jeder Client, der etwas abfragt, ein User der unbedingt eine hübsche Fehlerseite benötigt. Es gibt (wie schon oft erwähnt) auch Maschine-Maschine-Schnittstellen. Da legt man schlichtweg keinen Wert auf die Optik.

Was genau ist an "die()" denn grundsätzlich schlecht? So wurde es ja im eigentlichen, mMn streitbaren, Post dargestellt ....

 

[mercsen]

weil auch eine Maschiene -Maschiene schnittstelle i.d.r. dankbar für einen genaueren Fehler wäre als nur "Geht nicht und jetzt hau ab du spack und nerv mich nicht!"

mit die() gehts natürlich nicht, es sei denn man ruft in die() dann eine funktion auf die den Fehler genauer bestimmt.

Das sie Grundsätzlich schlecht ist wurde nicht behauptet, ich habe mehr als einmal gesagt das es situationen gibt wo sie durchaus sinn macht!

 

[Trainmaster]

Ein PC selbst schert sich nicht um irgendwelche Formatierungen oder Templates, wenn er Daten abruft - dafür interessiert sich nur ein Nutzer.

Wieso führst du zuerst das Beispiel mit einer Website an und argumentierst letztenendes mit einer API? Das sind doch grundlegend verschiedene Dinge. Eine gute API wird auch mehr als nur einen Fehlerstring zurückgeben.

 

[mercsen]

Naja, also viel mehr als einen Fehlerstring kannst du mit PHP nicht zurückgeben wenn es eine Schnittstelle für z.b. ein AJAX Script ist, aber auch da wäre es natürlich sinnvoll den Fehler näher zu spezifizieren

 

[voodoo44]

@Trainmaster
... aha ... und was ist genau daran eine "API"? Das Ganze ist schlichtweg (z.B. in Form eines WFS GetFeature-Response) auch nur eine Website - die gibt eben nur XML aus ....
Was gibt eine gute API denn mehr als einen String zurück?

@Mercsen
Warum kann ich das mit die() nicht?
die('<GetFeatureResponse><Error>Error: Could not connect to database</Error></GetFeatureResponse>');
Brauch ich nicht die ganzen restlichen Operationen ausprobieren, if-Abfragen o.ä. durchlaufen. Ohne Datenbankverbindung kann ich schlichtweg keine Features zurückgeben. Warum soll ich dann noch groß weitermachen?

 

[Belee]

Sehe ich genauso, wer ganz auf eine DB setzt sollte die Seite bei einem Problem komplett zu machen. Weil, wenn der Hauptcontent aus der DB kommt der dann aber fehlt, wird der User eh gehen. Also nicht ein die(blabla); sondern eine Fehlerseite, ne schöne große und fertig. Alles andere ist für den Besucher nur frustrierend, frustrierend weil ..., er klickt da = Fehlermeldung, dann klickt er dort = wieder Fehlermeldung, irgendwann sagt er sich dann ob man ihn verarschen wolle. Deshalb ist es meiner Meinung nach falsch den User doch auf die Seite zu halten oder ihm 20 kleine, für ihn eher nichtssagende Fehlermeldungen zu zeigen.

Schön finde ich Seiten die ihre Navigation auch noch in der DB gepackt haben na ob dem User dann noch irgendeine kleine Fehlerlmeldung was bringt will ich mal bezweifeln.
Viele reden hier von einer sauberen Struktur packen aber das Herz einer Seite "Navigation" dann auch noch in die DB.

 

[voodoo44]

Viele reden hier von einer sauberen Struktur packen aber das Herz einer Seite "Navigation" dann auch noch in die DB.

Es soll auch Leute geben, die ihre Templates aus einer Datenbank holen oder diverse Dinge wie Hintergrundfarben, CSS-Eigenschaften u.ä.