PHP 7 erschienen!

[RicoBrassers]

Ah okay, danke.
Also im Grunde fast wie ein String.format/printf, nur für SQL-Statements?

Mal schauen, ob ich mich dazu überreden kann, PreparedStatements in meinen nächsten Projekten zu verwenden. Vermutlich werde ich aus Gewohnheit bei den Escape-Strings bleiben

 

[Zeiss]

Ja, mehr oder weniger.

Ich entwickle für Oracle, da wird es immer genommen, allein schon Performance wegen.

 

[lowskill]

Wenn wir uns mit allem auseinandersetzen wollen, können wir auch gleich wieder in Assembler schreiben.

Das hätte einen sehr großen Vorteil: PERFORMANCE

War das jetzt Ironie?

 

[Zeiss]

Nein, das war keine Ironie.

 

[Gast1774861802]

Da hast Du es @Ap0ll0XT. PHP ist und bleibt einfach nur eine Bastelkiste, nicht mehr und nicht weniger.

Das ist einfach nur Ignoranz. Nicht mehr und nicht weniger. Gefühlt 80% der Webseiten etc. werden mit PHP betrieben. Ruby ist ne tolle Sprache, verwendet aber kein Schwein. NET oder Java im Web Bereich ? Ne danke. Hat seinen Grund warum das kein Mensch macht. Jemals was über eine große Sicherheitslücke bei Facebook gelesen ? Ne ? Wenn man mit PHP richtig programmiert hat man oben genannte Probleme auch nicht. Du verteufelst ja auch keine Autos weil man damit Menschen überfahren kann.

Der Nachteil ist, dass viele Leute diese Schnittstelle benutzt haben, weil sie in der Standardbibliothek vorhanden ist.
Meinetwegen kann man sie ja drinne lassen, aber zumindest sollte es bei der Ausführung zu einem Fehler kommen, wenn nicht in irgendeiner Config Datei ein Wert auf "Ja, ich möchte dass meine Datenbank für Injections anfällig ist" gesetzt ist.

Alles was als decprecated markiert ist löst eine notice/warning aus. Sofern diese nicht unterdrückt werden durch die besagte Config (display_errors, error_reporting).

 

[DarkMo]

Es ist eigentlich ganz einfach. Du hast ein Stement wie zum Beispiel (das ist jetzt Java, aber Prinzip ist derselbe):

sqlString = "select * from kunde where id = ?";

Das Dng "preparierst" Du, der Statement wird kompiliert. Das ? ist dabei der Platzhalter, wo der Wert eingesetzt wird. Im nächsten Schritt setzt Du den Wert ein:

PreparedStatement prepStat = conn.prepareStement (sqlString);
prepStat.setInt (1, 17);

Dabei sagst Du welcher Wert an welche Stelle im SQL eingesetzt wird, hier wird eine 17 an die Stelle 1 (gibt ja nur die) eingesetzt.

Danach

ResultSet rs = prepStatement.executeQuery();

Und Dein Resultset landet in rs, fertig.

PreparedStatement hat mehrere Vorteile, zum einen Sicherheit, zum Anderen ist es für die DB auch einfacher (das Statement an sich ist derselbe, nur die Bind-Variablen ändern sich) und zum Dritten kann man sie batchen.

Aber geht das nich auch mit normalem sql? Ich hab meinetwegen ein

$sql = "select * from table where id = ";

Das wäre doch grundsätzlich erstmal genau das gleiche. Ich habe meinen vorbereiteten sql-string und kann da nun was anhängen.

$sql.=$var;

Schon hab ich meinen Wert eingesetzt ^^

So, mir fallen auf Anhieb 1000 Unterschiede ein, was die Bequemlichkeit betrifft. Hier ists simpel, weil ich ja einfach was hinten anhäng. Bei mehreren Werten/komplexeren Abfragen wirds natürlich frickelig. Da könnte man mit ner Klassenstruktur und Objekten arbeiten. Aber spätestens dann hätte man doch genau das gleiche erreicht? WO ist da der Unterschied?

Wegen der Sicherheit und alten Turorials: dass man das nicht so simpel macht, wie hier im Bspw ist ja wohl hoffentlich klar und wird mE auch eigentlich überall erwähnt. Sowas konnte man doch auch mit alten Methoden absichern. addslashes, stripslashes, htmlentities oder was es da nich alles an funktionen gab, damit ein beliebiger String eben NICHT das eigentliche Statement abändern kann.

Wie gesagt: Bequemer mags sein, aber von der Sicherheit läufts doch aufs gleiche hinaus oder? Ehrlich gesagt würds mich auch garnich wundern, wenn das nix weiter is, wie eine Klassenstruktur, die intern auch wieder nur die alten Methoden nutzt ^^ Nur eben, dass man sich selber um die Sicherheitsaspekte nich mehr zu kümmern braucht.

 

[lowskill]

Nein, das war keine Ironie.

Ah, ja. Gibt sicher viele Programmierer, die auf ASM-Ebene besser optimieren als ein moderner Compiler. Wäre schon interessant, wie viel Prozent langsamer diese "optimierten" Programme im Durchschnitt laufen.

 

[RicoBrassers]

Aber geht das nich auch mit normalem sql? Ich hab meinetwegen ein

$sql = "select * from table where id = ";

Das wäre doch grundsätzlich erstmal genau das gleiche. Ich habe meinen vorbereiteten sql-string und kann da nun was anhängen.

$sql.=$var;

Schon hab ich meinen Wert eingesetzt ^^

So, mir fallen auf Anhieb 1000 Unterschiede ein, was die Bequemlichkeit betrifft. Hier ists simpel, weil ich ja einfach was hinten anhäng. Bei mehreren Werten/komplexeren Abfragen wirds natürlich frickelig. Da könnte man mit ner Klassenstruktur und Objekten arbeiten. Aber spätestens dann hätte man doch genau das gleiche erreicht? WO ist da der Unterschied?

Wegen der Sicherheit und alten Turorials: dass man das nicht so simpel macht, wie hier im Bspw ist ja wohl hoffentlich klar und wird mE auch eigentlich überall erwähnt. Sowas konnte man doch auch mit alten Methoden absichern. addslashes, stripslashes, htmlentities oder was es da nich alles an funktionen gab, damit ein beliebiger String eben NICHT das eigentliche Statement abändern kann.

Wie gesagt: Bequemer mags sein, aber von der Sicherheit läufts doch aufs gleiche hinaus oder? Ehrlich gesagt würds mich auch garnich wundern, wenn das nix weiter is, wie eine Klassenstruktur, die intern auch wieder nur die alten Methoden nutzt ^^ Nur eben, dass man sich selber um die Sicherheitsaspekte nich mehr zu kümmern braucht.

Aber bei deiner Variante könnte man mit SQLi arbeiten.

$var="1 or 1=1;"
$sql.=$var;

 

[DarkMo]

aber konnte man "var" nicht so absichern (quasi escapen als blöden vergleich ^^ hab scho lang nich mehr mit php und sql gearbeitet >< ), dass das or eben NICHT ausgewertet wurde? kann mir einfach nich vorstellen, dass das vorher nich ging und ne neue erfindung wäre ^^

 

[RicoBrassers]

aber konnte man "var" nicht so absichern (quasi escapen als blöden vergleich ^^ hab scho lang nich mehr mit php und sql gearbeitet >< ), dass das or eben NICHT ausgewertet wurde? kann mir einfach nich vorstellen, dass das vorher nich ging und ne neue erfindung wäre ^^

Ja, man könnte $var vorher noch escapen, das ist richtig.

$var=$db->real_escape_string($var);

Oder so ähnlich.

 

[Zeiss]

Das ist einfach nur Ignoranz. Nicht mehr und nicht weniger. Gefühlt 80% der Webseiten etc. werden mit PHP betrieben. Ruby ist ne tolle Sprache, verwendet aber kein Schwein. NET oder Java im Web Bereich ? Ne danke. Hat seinen Grund warum das kein Mensch macht. Jemals was über eine große Sicherheitslücke bei Facebook gelesen ? Ne ? Wenn man mit PHP richtig programmiert hat man oben genannte Probleme auch nicht. Du verteufelst ja auch keine Autos weil man damit Menschen überfahren kann.

Und wieviele von diesen 80% sind anfällig? Nur weil es jemand macht, heißt es noch lange nicht dass es gut ist. PHP ist super einfach und deswegen "kann" so gut wie jeder. PHP erlaubt Schweinereien, die in anderen Sprachen nicht gehen. Ich sage nur "implizite Variablendeklaration"... grausam.

eBay ist übrigens in C++ entwickelt, rennt wie Schwein und skaliert bombastisch... Und Facebook ist NICHT in PHP programmiert... sondern einer an PHP basierten Sprache, die eine Mischung aus PHP, Java und C#. Und jetzt rate mal warum das gemacht wurde?

Und Java im Webbereich funktioniert, richtig gut sogar. Dass es kein Mensch macht, ist einfach nur Schwachsinn. Die ganzen WebServices und SOAP und alles laufen unter was? Genau, zum größten Teil unter Java und meistens mit großen AppServer wie WebSphere oder WebLogic.

Ich verteufle PHP nicht. Wenn ich schnell was zusammenrotzen will, dann nehme ich PHP. Für andere Web-Sachen nehme ich Java auf Tomcat mit einem vorgeschalteten NGINX.

Wie gesagt: Bequemer mags sein, aber von der Sicherheit läufts doch aufs gleiche hinaus oder? Ehrlich gesagt würds mich auch garnich wundern, wenn das nix weiter is, wie eine Klassenstruktur, die intern auch wieder nur die alten Methoden nutzt ^^ Nur eben, dass man sich selber um die Sicherheitsaspekte nich mehr zu kümmern braucht.

Nein, eben nicht das Gleiche. Wenn Du von mir gezeigten Beispiel nimmst, dann wird da nichts konkateniert, sondern in eine vorbereitete "Struktur" eingesetzt.

Aus der SQL Sicht ist das:

$sql = "select * from table where id = ";
$sql.=$var;

etwas anderes als das hier:

String sqlString = "select * from kunde where id = ?";
PreparedStatement prepStat = conn.prepareStement (sqlString);
prepStat.setInt (1, 17);

zumindest bei Oracle. Und das ist für die spätere Optimierung und Ausführung von Bedeutung.

Ah, ja. Gibt sicher viele Programmierer, die auf ASM-Ebene besser optimieren als ein moderner Compiler. Wäre schon interessant, wie viel Prozent langsamer diese "optimierten" Programme im Durchschnitt laufen.

Es kommt drauf an, wo man sich bewegt. Im embedded Bereich kann man da sehr viel rausholen. Und es ist dort auch Gang und Gäbe, dass man Object-Code noch mal an zeitkritischen Stellen nochmal überarbeitet. Man verwendet zum Beispiel vermehrt Makros anstelle von Funktionen.

 

[Gast1774861802]

Und wieviele von diesen 80% sind anfällig? Nur weil es jemand macht, heißt es noch lange nicht dass es gut ist. PHP ist super einfach und deswegen "kann" so gut wie jeder. PHP erlaubt Schweinereien, die in anderen Sprachen nicht gehen. Ich sage nur "implizite Variablendeklaration"... grausam.

eBay ist übrigens in C++ entwickelt, rennt wie Schwein und skaliert bombastisch... Und Facebook ist NICHT in PHP programmiert... sondern einer an PHP basierten Sprache, die eine Mischung aus PHP, Java und C#. Und jetzt rate mal warum das gemacht wurde?

Und Java im Webbereich funktioniert, richtig gut sogar. Dass es kein Mensch macht, ist einfach nur Schwachsinn. Die ganzen WebServices und SOAP und alles laufen unter was? Genau, zum größten Teil unter Java und meistens mit großen AppServer wie WebSphere oder WebLogic.

Ich verteufle PHP nicht. Wenn ich schnell was zusammenrotzen will, dann nehme ich PHP. Für andere Web-Sachen nehme ich Java auf Tomcat mit einem vorgeschalteten NGINX.

Das stimmt nicht. Ja Facebook verwendet unter anderem auch Java und C++ usw. in unterschiedlichen Bereichen. Jede Firma verwendet unterschiedliche Sprachen. Ich code auch manches in Perl oder C# weil dort PHP einfach eine schlechte Wahl wäre. Aber Facebook basiert fast hauptsächlich auf PHP. Die haben HipHop bzw. HHVM bestimmt nicht entwickelt weil Sie Langeweile hatten. Keine Ahnung ob du mit "Mischung" HipHop meintest, aber das wäre dann auch falsch. Das ist nur der Interpreter. Das ist immer noch PHP-Code. Wenn du mir nicht glaubst, lies nach. Sicherlich ist PHP in solch großen Dimensionen keine gute Wahl. Aber wir reden hier nicht nur von den Big-Playern.

Mit "kein Mensch" meine ich das es einfach kaum verbreitet ist und das ist nun mal Fakt. Im Webbereich dominiert PHP immer noch um Längen. Es gibt leider keine Statistik die Webservices/Websites/Apps o.ä genau unterscheidet. Aber PHP dominiert den gesamten Webbereich mit weitem Vorsprung. APS, Coldfusion, Java teilen den kleinen Rest unter sich auf. Ich glaub dir das man was ordentliches mit Java auf die Beine stellen kann. Ich persönlich bin leider schon immer Java-Gegner gewesen. Schon bevor ich programmieren konnte. Da greife ich lieber zu C#. Trotzdem stelle ich die Sprache nicht als "rotz" dar oder "schmuddelkram". Was Sicherheit angeht steht Java auch nicht besser als PHP da. Flash/Java sind eigentlich die Hauptprobleme wenn es um Sicherheitslücken geht. Auch wenn es nicht mehr so schlimm ist wie es mal war.

Man darf auch nicht vergessen. PHP ist eine Skriptsprache. Sie mit Java und C++ zu vergleichen ist vollkommen falsch. Mit PHP kann ich mal eben ein Skript erstellen das eine Aufgabe erfüllt. Das heißt aber nicht das ich keine größeren Anwendungen damit erstellen kann.

Du widersprichst dir auch leider selbst "ich verteufle PHP nicht" und ein paar Wörter weiter "schnell was zusammenrotzen". Genau das ist die Mentalität die mir so auf die Nerven geht. Pure Ignoranz.

 

[Zeiss]

Ich persönlich bin leider schon immer Java-Gegner gewesen. Schon bevor ich programmieren konnte.

Du widersprichst dir auch leider selbst "ich verteufle PHP nicht" und ein paar Wörter weiter "schnell was zusammenrotzen". Genau das ist die Mentalität die mir so auf die Nerven geht. Pure Ignoranz.

Danke für's Gespräch.

 

[Gast1774861802]

Danke für's Gespräch.

Was ist daran falsch Java Programme nicht zu mögen ? Ich habe in keinem Wort gesagt das Java schlecht ist. C++ ist auch ne gute Sprache. Angenehm zu programmieren ist aber was anderes.

 

[RicoBrassers]

Die Java-Applets haben für die ganzen Sicherheitsprobleme gesorgt und die sind heutzutage zum Glück fast komplett ausgestorben.
Webapps, die im Backend auf Java setzen sind um längen sicherer (werden ja auch nicht auf dem Client ausgeführt). So ist zum Beispiel Jenkins (eine der bekanntesten CI-Programme) ebenfalls in Java geschrieben.

Java an sich ist auch keine blöde Sprache. Ich tendiere eher zu sagen, dass es einfach nur eine subjektive Ablehnung ist. Entweder, weil man etwas anderes gewohnt ist oder weil man ständig von negativen Schlagzeilen (wegen den kack Applets) hört. Also ich persönlich kann z.B. in Java besser programmieren, als in C++. Liegt daran, dass ich mit C++ erst vor ein paar Monaten angefangen habe und in Java bereits seit guten 4-5 Jahren programmiere, oder einfach, weil man in Java idealerweise nur eine Datei pro Klasse braucht (C++ braucht ja Code und Header, wenn ich mich nicht irre). Wie gesagt, jeder hat seine persönlichen Präferenzen.

Aber im Großen und Ganzen kann ich einigen hier nur zustimmen: Ich habe nichts gegen PHP, im Gegenteil. PHP war mal (nach Java) meine Lieblingssprache (Habe ich mich jetzt geoutet?).
Ich benutze sie derzeit auch nur, um einfachste Formulare oder Datenbankverbindungen zu schreiben. Für größere Projekte verwende ich mittlerweile NodeJS.
Auch wenn sich das eventuell dank PHP7 wieder etwas ändern könnte.

Blöde Frage: Man kann mit C++ auch im Web arbeiten (Backend)? Wusste ich noch gar nicht. Bisher war mir das nur von Asp.NET bekannt (Visual Basic, C#).

 

[DarkMo]

Aus der SQL Sicht ist das:

$sql = "select * from table where id = ";
$sql.=$var;

etwas anderes als das hier:

String sqlString = "select * from kunde where id = ?";
PreparedStatement prepStat = conn.prepareStement (sqlString);
prepStat.setInt (1, 17);

zumindest bei Oracle. Und das ist für die spätere Optimierung und Ausführung von Bedeutung.

das klingt etwas verquer ^^ WIE der anfrage string zusammen gesetzt wird, kann der DB herzlich egal sein, oder nich? die DB erhält nur die Anfrage. um konkret zu werden müsstest du einen konkreten endgültigen anfrage-string mal "malen". was wird bei einem prepared statement aus "1 or 1=1"? und ich bin mir sehr sehr sicher, dass man diese anfragestruktur auch mit "normalem" php bla hinbekommt. im endeffekt wird der ganze teil "1 or 1=1" in irgendeiner weise im string markiert, so dass die DB das or NICHT auswertet. und das kannste auch in nem ganz normalen string machen ^^ DAS meinte ich.

prepared statements mögen einen bequemen weg darstellen, wenn man sich anstrengt, bekommt man das ohne aber auch hin (bin ich der meinung).

bspw schreibt man halt nicht
select * from kunde where id = ?
sondern
select * from kunde where id = '?'

schon steht das or innerhalb der anführungszeichen und der ganze inhalt der variablen wird als wert angesehn (welcher in dem fall schlicht ungültig ist). hab schon länger nix mehr mit datenbanken gemacht, daher weiß ich jetz nich, ob das so ausreichend ist und stimmt, aber das prinzip sollte deutlich werden.

 

[RicoBrassers]

PHP: Prepared Statements - Manual

Der Vorteil von PreparedStatements ist halt, dass das "Query template", also unser "select * from kunde where id = ?" nur ein einziges Mal zum DB-Server geschickt wird (Wenn man die Query häufiger ausführt).
Wenn man nur eine einzelne Query abschickt, mag ein normales Escapen reichen, aber wenn man ein Template häufiger (hintereinander) benutzt, kann man mit PreparedStatements eine etwas bessere Performance erreichen.

 

[bingo88]

Das hatte ich doch alles schon in Post #19 geschrieben

 

[DarkMo]

asö! na das is ja dann auch was andres ^^ davon hat aber bisher irgendwie nie einer gesprochen >< also wird diese vorbereitete anfrage schon an die db geschickt und dort wird dann nur noch die gewünschte variable hinzugefügt? hmm, aber dennoch muss die DB bei jeder neuen variable ne neue anfrage intern erstellen, dächt ich. also man spart nen bissl an übertragungs-bandbreite und die db weis eben ganz genau, dass das, was da folgt nur werte sind (was dann wirklich der entscheidende vorteil is). aber direkte performance-zuwächse könnt ich mir gerade dennoch nich vorstellen.

dazu müsste die db ja eine vollständige view der "ungefilterten" (also ohne variable filter) anfrage abspeichern und diese dann je nach variablem filter erneut durchackern (aber eben ein kleiner datenbestand wie die ganze db ^^). dennoch würde man doch aber irgendwann unweigerlich auf veralteten daten arbeiten. eigentlich unvorstellbar, dass das so abläuft.

 

[RicoBrassers]

Das hatte ich doch alles schon in Post #19 geschrieben

Weiß ich, ich habe es auch nur nochmal aufgefasst, weil es gerade passend war.
Argument-Recycling

@DarkMo

MySQL 5.7 provides support for server-side prepared statements. This support takes advantage of the efficient client/server binary protocol. Using prepared statements with placeholders for parameter values has the following benefits:

Less overhead for parsing the statement each time it is executed. Typically, database applications process large volumes of almost-identical statements, with only changes to literal or variable values in clauses such as WHERE for queries and deletes, SET for updates, and VALUES for inserts.

Protection against SQL injection attacks. The parameter values can contain unescaped SQL quote and delimiter characters.

MySQL :: MySQL 5.7 Reference Manual :: 13.5 SQL Syntax for Prepared Statements