Hochkomma fehlt? Wann fehlermeldungen?

[Forumsgast]

Hi,

ich wollte nur mal fragen wann und warum es zu Fehlermeldungen kommen kann, wenn dieses Hochkomma fehlt?

` spaltenname `

Ich hatte eben eine relativ einfach Standartabfrage und dort wurde mir immer NULL ausgegeben mit var_dump()

Mit folgenden Hochkommas um die Spalten herum geht es jetzt. Und wenn ich " * " nehme funktioniert es auch.

$ad=mysql_fetch_array(mysql_query("SELECT `if`,`max` FROM tab WHERE `id`='1'"));
var_dump($ad); 

Also dies ist/war definitiv eine einfache Standardabfrage gerade wo ich ohne diese noch nie Probleme hatte...

[Forumsgast]

das Problem sind sogenannte "reservierte Worte" = Worte, die selbst für den SQL-Interpreter Befehle darstellen

if und max sind solche reservierten Worte - dann brauchst du diese Backticks, um dem SQL-Interpreter zu sagen "das was jetzt kommt, ist definitiv ein Bezeichner für eine Datenbank oder Tabelle oder Spalte)

[marcoschaefer19]

Ok. Danke für den Hinweis Habe gerade vergeblich versucht den Fehler zu finden weil ich dies nicht wusste. Also sollte man Spaltennamen besser grundsätzlich in `Anführungszeichen `setzen?

[Forumsgast]

Ok. Danke für den Hinweis Habe gerade vergeblich versucht den Fehler zu finden weil ich dies nicht wusste. Also sollte man Spaltennamen besser grundsätzlich in `Anführungszeichen `setzen?

Nein. Ich mache dies nie.

Andreas

[Forumsgast]

das hilft zumindest solche Probleme zu Umgehen - mit Backticks darfst du sogar Leerzeichen in den Bezeichnern haben, sonst müssen das immer einzelne Worte sein

Ein wenig Vorsicht bei Kopplungen aus Tabellen+Spaltenname

`tabelle1`.`feld1`

musst du das schreiben, sonst wird auch der Hierarchie-Trenner (punkt) als Bestandteil des Tabellen-Namens bzw Feldnamens gewertet und du bekommst den unerwarteten Fehler "unknown column in ..."

[marcoschaefer19]

Nein. Ich mache dies nie.

Ok. Ich nämlich auch nicht, hab das nur mal mit so aufgeschnappt mit den Hochkommas und auch nur deswegen überhaupt so getestet.

`tabelle1`.`feld1`

musst du das schreiben, sonst wird auch der Hierarchie-Trenner (punkt) als Bestandteil des Tabellen-Namens bzw Feldnamens gewertet und du bekommst den unerwarteten Fehler "unknown column in ..."

Das wäre dann bei INNER JOIN zum Beispiel?

Ich ziehe aus dem das ich dies nur Schreiben muss, wenn der Spaltenname gleich ist wie eine Anweisung innerhalb MySQL? Ansonsten wäre weglassen wenn diese nicht gleich sind denke ich auch besser? Wenn auch nur geringfügig die Ladezeit reduziert wird. Oder liege ich damit falsch?

[Forumsgast]

das hat auf die Zeit überhaupt keinen Einfluss (2 Zeichen im Query-String) - eher würde ich erwarten, das explizites Festlegen "das nachfolgende ist ein Bezeichner" dem SQL-Interpreter hilft schneller zu entscheiden (sonst versucht er es erst als SQL-Befehl zu interpretieren und schaut danach in die Tabelle(n) der Abfrage) - aber im Normalfall ist der SQL-Interpreter so schnell, dass die Auswirkungen allerhöchstens messbar sind (im nanosekunden-Bereich)

Aber pass halt auf, dass du keine reservierten Worte erwischst ...
Wenig verkehrt machen kannst du, wenn sämtliche Spalten und Tabellen-Namen ausschließlich DEUTSCH sind (bitte aber auf Umlaute verzichten) - denn sämtliche SQL-Befehle sind quasi "naturgegeben" englisch

aber nochmal .. das sind keine HOCHKOMMAs -- Hochkomma ist der einfache Quote, den du um Zeichenketten oder Datum/Zeitwerte in Abfragen verwendest .. diese Zeichen heißen Backticks im MySQL-Kontext

Andere Datenbanksysteme verwenden dafür auch andere Zeichen .. MSSQL zum Beispiel eckige Klammern [dbo].[tabelle].[spalte]

[marcoschaefer19]

Ok. Gute Hinweise.
Naja gut die meisten Spaltennamen benenne ich auch auf Deutsch
In diesem Fall waren es halt Abkürzungen, die gleich zufällig beide eine MySQL Bedeutung hatten. Darum ist mir dies aufgefallen.

aber im Normalfall ist der SQL-Interpreter so schnell, dass die Auswirkungen allerhöchstens messbar sind (im nanosekunden-Bereich)

Also ich versuche meinen Code egal an welcher Stelle so kurz wie möglich zu halten. Angefangen bei Spaltenbezeichnung in der Datenbank oder Tabellennamen. Auch die Variablennamen im Code sind meist recht kurz bei mir. Es kommt aber auf das Script auch etwas an was ich genau schreibe. Ich kürze nur stark ab, wenn ich weiß das ich mich danach noch damit zurechtfinde

[Forumsgast]

das ist unsinnig - PHP startet als erstes einen Parse-Durchgang - danach wird der Byte-Code des Scriptes verwendet - und dadrin gibt es gar keine Variablennamen mehr, sondern konkrete Speicheradressen ...du solltest Bezeichner immer so lang wählen, dass sie ausreichend informativen Namen tragen - spätestens nach ein paar Wochen weißt du sonst nicht mehr, was eine Variable $aa transportiert ... genau bei den Spaltennamen der Datenbank. Wähle aussagekräftige Namen. Es hilft hier wenig mit kryptischen Abkürzungen zu operieren - diese micro-Optimierungen helfen nicht wirklich Rechenzeit zu sparen , machen aber die Fehlersuche schwer

[marcoschaefer19]

Achso.
Ich dachte immer je kürzer je besser

- PHP startet als erstes einen Parse-Durchgang - danach wird der Byte-Code des Scriptes verwendet - und dadrin gibt es gar keine Variablennamen mehr, sondern konkrete Speicheradressen

Und wie ist es wenn ich die Zeilen möglichst mit wenig Leerzeichen und Zeilenumbrüchen schreibe? Also ich habe dies getestet, eine "normale" Datei geschaut wieviel Bytes diese hatte und dann habe ich den Code "optimiert". Dies macht so bei einen Durchschnittsscript dann ca. 1/3 Speicherkapazität aus. 25-40% waren es meist. Habe nicht nur eine Datei so überprüft.
Deswegen dachte ich auch das muss gut so sein. Auch habe ich mir Startzeit und Endzeit des Scriptes ausgeben lassen. Vorher und Nachher und dies war etwas schneller.

[Forumsgast]

du schaust da nur auf den Quellcode - wie gesagt nach dem Parse-Durchgang enthält der ByteCode aber keine Zeilenumbrüche mehr . du kannst dir den ByteCode wie Maschinencode vorstellen (nur noch eine lange Folge von 0en und 1en) - der einzige Unterschied ist, dass normalerweise Maschinencode "prozessorspezifisch" ist - also Code für den Intel x86 Code sieht anders aus, als zum Beispiel Code für nen MIPS- Prozessor (hat zum Beispiel Silicon Graphics in ihren GrafikWorkstations verbaut) ... der PHP-Bytecode ist nicht prozessorspezifisch, sondern muss nochmal interpretiert werden - aber das geht dann sehr schnell

Das einzige, was deine Micro-Optimierungen vereinfachen ist das Parsen zum Byte-Code .. und das passiert genau EIN MAL (im Idealfall)

[marcoschaefer19]

Kann ich mir so einen Parse-Vorgang anschauen, also Live bei mir wenn sich die Seite erstellt? Rein einmal aus Interesse.

Das einzige, was deine Micro-Optimierungen vereinfachen ist das Parsen zum Byte-Code .. und das passiert genau EIN MAL (im Idealfall)

Wenn jemand auf meine Seite kommt, dann ist dies doch trotzdem wichtig, dass es so weit es geht optmiert wurde? Also im Admin-Bereich lege ich darauf auch nicht zu großen Wert, z.B. mal ein Kommentar oder eine kurze Erklärung, aber dort wo User kommen ... Also wenn ich Surfe, als User, nicht beim Programmieren selbst, da klicke ich eine Seite die lange dauert weg...

[Forumsgast]

vermutlich liegt der Bytecode entweder im tmp-Ordner oder einem Arbeitsverzeichnis des Webservers

Auf jeden Fall gibt es aber sogenannte ByteCode-Caches, die den Webserver dahingehend optimieren, dass die Ladezeit für die ByteCode-Dateien entfällt ...

Such mal nach APC

[marcoschaefer19]

http://de.wikipedia.org/wiki/Alternative_PHP_Cache

.. bei wiederholter Ausführung das zeitaufwändige Kompilieren nahezu vollständig vermieden werden kann ...

Ich lade eine Website hoch, klicke mich einmal hier durch. Wenn ich dies getan habe, ist sozusagen alles was mit Parsen zusammenhängt im Cache des Webservers und wird dann immer aus dem Cache gelöscht. Oder habe ich dies falsch verstanden? Dann würde aber Änderungen am Script nicht bedingt festgestellt werden... Dann frage ich mich und euch was kann man machen, dass Dateien aus den Cache vom Webserver gelöscht werden, auf welchen ich gar keinen Zugriff im eingentlichen Sinne habe. Ich kann bei meinen Webserver nicht einmal das Timelimit erhöhen oder sonstiges ... Den Cache auf meinen PC entferne ich einfach mit CCleaner und weg ist es.

APC in der PHP Version 6.0 fest zu integrieren, so dass APC nativ zur Verfügung steht.

Diesen könnte man denke ich dann nutzen, um z.B. Bilder oder Design in den Cache zu schieben, sodass Ladezeiten dahingehend auch verringert werden. So eine Art Cookies.
Oder liege ich da falsch?

Marco

[Forumsgast]

Diesen könnte man denke ich dann nutzen, um z.B. Bilder oder Design in den Cache zu schieben, sodass Ladezeiten dahingehend auch verringert werden. So eine Art Cookies.
Oder liege ich da falsch?

Ja, tust du. Nativ heißt nicht, dass beim User gecached wird. Browser-Caches existieren schon etwas länger.