Profil | Mitglieder | Registrieren | Start | Suche


PHP-Support.de » PHP-Einfach » News » Relaunch PHP-Einfach.de    » Hallo Gast [Login | Registrieren]

Neues Thema | Antworten   

Autor Beitrag
FalkenaugeMihawk
Mitglied
Perfekter User


Dabei seit: 05.06.2010
Herkunft: Schweiz
Posts: 2617
      Zitat | Bearbeiten

Zitat:
Orginal von DingsDaBums
Zitat:
Orginal von FalkenaugeMihawk
Zitat:
Orginal von DingsDaBums
Zitat:
Orginal von FalkenaugeMihawk
[...]
Wir wollen ja nicht, das PDO Prepared Statements emuliert.

[...]

Wieso nicht? Da es nicht unsicherer* ist und die wenigstens Anwendungen wirklich von dem möglichen Geschwindigkeitsgewinn von Prepared Statements profitieren, würde ich das aufgrund der Performance erst wirklich einschalten, wenn ich entsprechende Fälle habe, wo die Anwendung wirklich von Prepared Statements profitiert.
Sonst bremst es die Anwendung nur unnötig aus, auch wenn man das natürlich in 99% der Anwendungen nicht groß merken wird, aber das gilt eben noch mehr für "echte" Prepared Statements.

Und wenn wir mal ehrlich sind, setzen die meisten Prepared Statements nur wegen der erhöhten Sicherheit ein. Die wenigstens setzen es ein, weil sie eine Abfrage mehrmals hintereinander einsetzen.

Das sollte man zumindest entsprechend thematisieren, bevor jeder einfach etwas 1:1 abschreibt und nicht genau weiß, wieso das so ist und je nach dem seine Skripte ausbremst oder so.

Nun, es geht ja darum, das PHP nicht die Werte parst bevor sie an MySQL gesendet werden. Denn nur so gibt man einem möglichen Angreifer keine Chance schädlichen SQL einzufügen.

http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php/60496#60496


Es geht in erster Linie bezüglich SQL-Injection darum, dass die Parameter/Werte nicht die Abfrage selbst verändern können sollen, was leicht der Fall ist, wenn man die Parameter "unbehandelt" einfach mit der Abfrage in einen Topf wirft und daraus einen String erstellen lässt, wo der Datenbank-Server schließlich nicht mehr erkennen kann, dass die Parameter die Abfrage wohl möglich manipuliert haben, weil die Datenbank einen einfachen String bekommt und Parameter nicht von der Abfrage unterscheiden können.

Prepared Statements bieten sich da natürlich als Lösung an, weil man die Abfrage und die Parameter separat voneinander an den Server schickt.
Trotzdem kann man dieselbe Sicherheit auch durch das einzelne Escapen aller Werte erreichen, nur kann es da ja auch vorkommen, dass man vielleicht etwas übersieht, was bei Prepared Statements nicht so schnell passiert, aufgrund deren Funktionsweise mit dem Parameter "binden".

Jetzt nutzt man PDO aber wie native Prepared Statements, wodurch PDO entsprechend weiß, was die Abfrage ist und was die Parameter sind. So kann PDO auch alle Parameter entsprechend escapen und so SQL Injection verhindern, ohne etwas einfach zu vergessen. Was SQL-Injections angeht, ist es egal, ob PDO wirklich beides separat an den Server schickt oder vorher sicher miteinander verbindet.

Prepared Statements sind ja nicht nur für die Sicherheit da, sondern ermöglichen einem vor allem das schnellere Ausführen von Abfragen, die oft hintereinander kommen, wo sich aber nur die Werte ändern, aber nicht die Logik der Abfrage an sich. Nur kostet das eben auch ein wenig mehr Zeit, als einfach nur einmal einen String zu interpretieren und auszuführen.

Da die wenigsten aber wirklich Fälle haben, wo sie eine Abfrage sehr oft mit verschiedenen Werten an die Datenbank schicken, wird je nach dem "unnötigerweise" die Abfrage von den Werten separat gesendet und interpretiert, was es generell sogar langsamer macht.


Dementsprechend würde ich nicht generell empfehlen, dass man diese Einstellung auf jeden Fall auf false setzen sollte (auch wenn es vielleicht bei den meisten keinen Unterschied machen wird), sondern eben eher einfach die entsprechenden Unterschiede erklären und Beispiele nennen, wo es entscheidend sein kann, dass man diese Einstellung auf false setzt und wirklich native Prepared Statements verwendet und sie nicht nur emuliert, um eben das zutun, was ja das eigentliche Ziel eines Tutorials ist: Wissen weitergeben und nicht einfach nur Code-Beispiele nennen, die einfach blind 1:1 kopiert werden können und es wahrscheinlich dann auch werden.
Am Ende des Tutorials sollte der Leser lieber selbst zumindest grob einschätzen können, ob er es bei sich extra auf false setzt und sollte wissen, dass es bei ihm wahrscheinlich keinen großen Unterschied machen wird und er sich die Zeile Code sparen kann oder es entsprechend auf false setzt, nur um ein noch sichereres Gefühl zu bekommen.

Ist zumindest meine Meinung und würde meiner Meinung nach die Qualität des vermittelten Wissens nochmal ein Stück steigern, wenn man bei solchen Dingen ein wenig mehr Hintergrundwissen dazu gibt, als nur zu sagen "Das ist genau so richtig".






Natürlich gehts bei Prepared Statements nicht nur um Sicherheit. Aber das ist ja primär das Ziel von Prepared Statements, das SQL Injections keine Chance haben und wenn man jetzt anfängt zu escapen, vernichtet man das Ziel, zwar weitgehend weniger als wenn man mit den alten `real_escape_string()` Funktion arbeitet, aber die Chance ist dennoch da, das es doch jemand schafft. Weshalb man immer auf native Prepared Statements setzen sollte, um den Template-Query von den Werten sicher zu trennen, so das man nicht irgendwie den Query unterbrechen kann und dann etwas anderes tun.

Ich weiss nicht ob es dein Ziel ist, zu vermitteln das es im Prinzip scheiss egal ist ob man jetzt native Prepared Statements benutzt oder nicht, denn wie du ja gesagt hast ist der Performance-Unterschied klein und wo möglich für die meisten nicht bemerkbar/vorhanden. Dennoch ist der Unterschied zwischen der Herangehensweise vom absolut getrennten Senden von Template-Query und Werten zu Escapen bemerklich da. Auch wenn die Chance kleinlich gering ist, würde ich diese nicht gegen den bisschen Performance-Gewinn eintauschen.

Für mich zählt primär die Sicherheit, Performance ist da eher sekundär. Wenn ich etwas mehr Sicherheit bekomme, für ein bisschen weniger Performance, dann kann ich damit leben. Ich weiss das es Menschen gibt, für die ist Performance das absolute Ziel, zu Gunsten (oder eher Opferung) von allem. Dennoch erachte ich es als absolut notwendig, das Benutzereingaben absolut getrennt von Prozessen zur Datenmanipulation verarbeitet werden um die Daten-Sicherheit höchstmöglich zu gewährleisten, auch im Sinne des Gesetzes und in erster Linie der Drittperson, der diese Webseite benutzt.


26.08.2015, 00:21 Profil | PM | E-Mail  
DingsDaBums
Mitglied
Exzellenter User


Dabei seit: 12.09.2010
Herkunft: keine Angabe
Posts: 2446
      Zitat | Bearbeiten

Zitat:
Orginal von FalkenaugeMihawk
[...]

Natürlich gehts bei Prepared Statements nicht nur um Sicherheit. Aber das ist ja primär das Ziel von Prepared Statements, das SQL Injections keine Chance haben und wenn man jetzt anfängt zu escapen, vernichtet man das Ziel, zwar weitgehend weniger als wenn man mit den alten `real_escape_string()` Funktion arbeitet, aber die Chance ist dennoch da, das es doch jemand schafft. Weshalb man immer auf native Prepared Statements setzen sollte, um den Template-Query von den Werten sicher zu trennen, so das man nicht irgendwie den Query unterbrechen kann und dann etwas anderes tun.

Ich weiss nicht ob es dein Ziel ist, zu vermitteln das es im Prinzip scheiss egal ist ob man jetzt native Prepared Statements benutzt oder nicht, denn wie du ja gesagt hast ist der Performance-Unterschied klein und wo möglich für die meisten nicht bemerkbar/vorhanden. Dennoch ist der Unterschied zwischen der Herangehensweise vom absolut getrennten Senden von Template-Query und Werten zu Escapen bemerklich da. Auch wenn die Chance kleinlich gering ist, würde ich diese nicht gegen den bisschen Performance-Gewinn eintauschen.

Für mich zählt primär die Sicherheit, Performance ist da eher sekundär. Wenn ich etwas mehr Sicherheit bekomme, für ein bisschen weniger Performance, dann kann ich damit leben. Ich weiss das es Menschen gibt, für die ist Performance das absolute Ziel, zu Gunsten (oder eher Opferung) von allem. Dennoch erachte ich es als absolut notwendig, das Benutzereingaben absolut getrennt von Prozessen zur Datenmanipulation verarbeitet werden um die Daten-Sicherheit höchstmöglich zu gewährleisten, auch im Sinne des Gesetzes und in erster Linie der Drittperson, der diese Webseite benutzt.


Du hast das Ganze glaube ich noch nicht so verstanden. Ob die diese Option nun true oder false ist, ändert nichts an der Sicherheit und nichts daran, dass man im Code die Werte getrennt von der Abfrage an PDO weitergibt.
Also bleibt der Code und die Sicherheit vor SQL-Injections genau gleich, was aus den genannten Gründen auch nicht anders sein dürfte, weil eben keine Fehlermeldung ausgegeben wird, wenn Prepared Statements nicht unterstützt werden, sondern eben ein entsprechender Fallback vollzogen wird, der ja dann je nach Fall unbemerkt ein großes Sicherheitsrisiko darstellen würde...

Das nicht unbedingt nutzen von nativen Prepared Statements bezieht sich auf diese eine Option... Wie PDO also arbeitet und nicht man selbst. Für einen persönlich und für die Sicherheit macht es also keinen Unterschied, ob man nun die Option auf true oder false setzt und entsprechend habe ich auch nicht geschrieben, dass man nicht die Abfrage-Logik getrennt von den Werten halten sollte. Man sollte nur nicht blind immer irgendeinen Code kopieren und einfach so als "richtig" darstellen, ohne ihn und die "Folgen" wirklich verstanden zu haben, weil z.B. du es jetzt schon so darstellst, als wäre das ein Muss, weil es die Sicherheit erhöhen würde, was aber einfach nicht stimmt. Da habe ich eher den starken Eindruck, als hättest du diese Option einfach mal in einem Tutorial "gefunden" und hast dich durch den Namen bzw. durch das "es werden Prepared Statements nur emuliert" schocken lassen, was natürlich auf den ersten Blick schockierend klingt, aber sich nach ein wenig recherchieren oder sogar selbst ausprobieren als nicht kritisch und sogar verständlich/nützlich erweist.

Da also die Option nichts daran ändert, dass man im Code immer noch Prepared Statements normal verwendet, die Sicherheit auch nicht besser oder schlechter ist, sollte man entsprechend nicht einfach nur sagen "Setzt diese Option auf false", sondern eben entsprechend kompetent auf die Hintergründe (wie beschrieben) eingehen.
Ich habe ja nicht gesagt, dass das auf false stellen dieser Option falsch oder richtig wäre, sondern eben nur, dass man nicht eine der Varianten ohne Erklärung als die einzig richtige Antwort darstellen sollte, was halt einfach nicht stimmt.

Edit:
Ich finde, dass diese Antwort das Ganze recht gut zusammenfasst. http://stackoverflow.com/questions/10113562/pdo-mysql-use-pdoattr-emulate-prepares-or-not


Schau mal bei meinem Projekt vorbei. Vielleicht ist das ja was für dich MyStartPanel - Deine persönliche Startseite mit deinen Favoriten
Auf der Suche nach einem guten Vokabeltrainer? Vokabeltrainer Cramfire - Schnell und effektiv Vokabeln lernen

Post wurde schon 1x editiert, das letzte mal am 26.08.2015 um 11:27 von DingsDaBums
26.08.2015, 10:21 Profil | PM | E-Mail  
Htaccess
Mitglied
Sehr guter User


Dabei seit: 22.08.2010
Herkunft: Deutschland
Posts: 703
      Zitat | Bearbeiten

Hier wird ja heiß diskutiert über native Prepared Statements. Im Vorfeld möchte ich erwähnen, dass ich nicht wirklich davon Ahnung habe, wohlmöglich weil ich mich damit nie wirklich beschäftigt habe. Was ich aber so gelesen habe und wenn ich es richtig interpretiert habe, geht es DingsDaBums darum das man unterscheiden soll zwischen Performance und Sicherheit der Scripte und FalkenaugeMihawk geht primär um die Sicherheit.

Wäre es nicht sinnvoller die native Prepared Statements als zusätzliches Thema mit aufzugreifen und die Funktionsweise genauer zu erläutern, wo und wann man zum Beispiel native Prepared Statements einsetzt? Den Code in dem zuletzt geposteten Link von DingsDaBums habe ich mal aufgegriffen und ein bisschen umgeschrieben. Villeicht kann man den ja verwenden:

 PHP 
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:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
<?php

function PDOconnect$settings$driver='mysql'$security=false ) {
    
$pairs = array();
    
$params array_fill_keys(array(
        
'host''port''socket',
        
'dbname''charset'
    
), NULL);
    
    
$arr array_intersect_key($settings$params);
    
$arr += $params;
    
    
$opt = array(
        
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
        
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
    
);
    
    if ((isset(
$arr['charset']))
        && (!empty(
$arr['charset']))
        && (
version_compare(phpversion(), '5.3.6''<'))
    ) {
        
$opt[PDO::MYSQL_ATTR_INIT_COMMAND] = 'SET NAMES ' $arr['charset'];
    }
    
    foreach(
$arr as $key => $val) {
        if (
$val === NULL) {
            continue;
        }
        
        
$pairs[] = "{$key}={$val}";
    }
    
    
$dsn $driver ':' implode(';'$pairs);
    
$pdo = new PDO($dsn$settings['username'], $settings['password'], $opt);
    
    if (
$security === true) {
        
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, (version_compare($pdo->getAttribute(PDO::ATTR_SERVER_VERSION), '5.1.17''<')));
    }
    
    return 
$pdo;
}





Post wurde schon 4x editiert, das letzte mal am 27.08.2015 um 11:10 von Htaccess
27.08.2015, 09:53 Profil | PM | E-Mail  
DingsDaBums
Mitglied
Exzellenter User


Dabei seit: 12.09.2010
Herkunft: keine Angabe
Posts: 2446
      Zitat | Bearbeiten

Zitat:
Orginal von Htaccess
Hier wird ja heiß diskutiert über native Prepared Statements. Im Vorfeld möchte ich erwähnen, dass ich nicht wirklich davon Ahnung habe, wohlmöglich weil ich mich damit nie wirklich beschäftigt habe. Was ich aber so gelesen habe und wenn ich es richtig interpretiert habe, geht es DingsDaBums darum das man unterscheiden soll zwischen Performance und Sicherheit der Scripte und FalkenaugeMihawk geht primär um die Sicherheit.

Wäre es nicht sinnvoller die native Prepared Statements als zusätzliches Thema mit aufzugreifen und die Funktionsweise genauer zu erläutern, wo und wann man zum Beispiel native Prepared Statements einsetzt? Den Code in dem zuletzt geposteten Link von DingsDaBums habe ich mal aufgegriffen und ein bisschen umgeschrieben. Villeicht kann man den ja verwenden:

[...]

Na ja, ich persönlich würde es durch so einen Code-Schnipsel jetzt nicht noch komplizierter machen.

Mir geht es einfach nur darum, dass man nicht so einen Stück Code einfach als gegeben ansehen sollte, sondern erklären sollte, was der Grund dafür ist oder sein kann, diese Einstellung auf false oder eben true zu setzen. Und eben nicht einfach sagen, dass man es auf jeden Fall auf false setzen sollte, nur um angeblich die Sicherheit zu erhöhen, was so aber halt nicht stimmt.

Und da wie gesagt native Prepared Statements für die meisten Anwendungsfälle sogar kleine Nachteile hat, die sich bei größeren Anwendungen schon bemerkbar machen können, sollte man entsprechend beide Möglichkeiten erklären und erwähnen, wann es Sinn macht diese Option auf true zu setzen oder zu lassen oder eben auf false.

Der PHP-Code ändert sich ja nicht wirklich, außer eben diese eine Zeile Code, die man eben je nach dem sogar einfach weglassen kann und dann entscheidet PDO schon selbst, welche Einstellung verwendet wird (je nach Datenbanksystem zumindest).
Und wenn so eine Zeile je nach Anwendung einen spürbaren Unterschied machen kann, würde ich es recht erklären wann und wieso und es wie schon erwähnt nicht auf eine Variante die "richtig" ist festlegen.




Schau mal bei meinem Projekt vorbei. Vielleicht ist das ja was für dich MyStartPanel - Deine persönliche Startseite mit deinen Favoriten
Auf der Suche nach einem guten Vokabeltrainer? Vokabeltrainer Cramfire - Schnell und effektiv Vokabeln lernen
27.08.2015, 11:43 Profil | PM | E-Mail  
Htaccess
Mitglied
Sehr guter User


Dabei seit: 22.08.2010
Herkunft: Deutschland
Posts: 703
      Zitat | Bearbeiten

Kannst du mir denn Vor- und Nachteile von native Prepared Statesments und auch mit Beispielen aufführen? Mich interessiert das und ich finde aktuell durch die Google SuFu nichts sinnvolles, dass es mir genaustens beschreibt bzw. erklärt, wann und wo man es einsetzen sollte.

Stattdessen habe ich verschiedene Anwendungsbeispiele gefunden, dass es einige in der prepare()-funktion als zweiten Parameter im Array angeben haben und andere Anwendungsbeispiele habe ich gefunden, wo es direkt beim Verbindungsaufbau in den optionen gesetzt wird.

Was ich auch noch interesannt finden würde, wären villeicht Benchmarktests


27.08.2015, 11:57 Profil | PM | E-Mail  
DingsDaBums
Mitglied
Exzellenter User


Dabei seit: 12.09.2010
Herkunft: keine Angabe
Posts: 2446
      Zitat | Bearbeiten

Zitat:
Orginal von Htaccess
Kannst du mir denn Vor- und Nachteile von native Prepared Statesments und auch mit Beispielen aufführen? Mich interessiert das und ich finde aktuell durch die Google SuFu nichts sinnvolles, dass es mir genaustens beschreibt bzw. erklärt, wann und wo man es einsetzen sollte.

Stattdessen habe ich verschiedene Anwendungsbeispiele gefunden, dass es einige in der prepare()-funktion als zweiten Parameter im Array angeben haben und andere Anwendungsbeispiele habe ich gefunden, wo es direkt beim Verbindungsaufbau in den optionen gesetzt wird.

Was ich auch noch interesannt finden würde, wären villeicht Benchmarktests


Bei einer einfachen Abfrage wird halt einfach nur ein String an die Datenbank geschickt, dieser interpretiert und eben ausgeführt.

Bei Prepared Statements wird halt erst die Abfrage an den Server geschickt, interpretiert und dann kommen die eigentlichen Werte.
Das hat den großen Vorteil, dass wenn man oft hintereinander dieselbe Abfrage ausführen möchte, wo sich nur die Werte ändern, der Server die Abfrage an sich nicht immer wieder neu interpretieren muss, sondern einfach die eine Abfrage immer mit den anderen (oder gleichen) Werten ausführen.
Dieser Vorteil kann aber halt auch je nach dem zum Nachteil werden, wenn man eben viele komplett verschiedene Abfragen hat, die in dieser Form nur 1-2 mal ausgeführt werden, wo das neu interpretieren der Abfrage eh immer durchgeführt werden muss, aber der ganze andere "Overhead" von wegen separat schicken von Abfrage und Daten bei jeder Abfrage dazu kommt, obwohl er eben nicht den wirklichen Vorteil ausspielen kann.

Aber wie auch schon erwähnt, merkt man die Unterschiede bei den meisten Anwendungen auch nicht. Dafür sind die Abfragen an sich einfach schon "zu einfach" bzw. nicht so komplex, als dass es wirklich ins Gewicht fällt.
Bei richtigen Anwendungen, die schon komplexer sind und auch mehr aktive Nutzer haben, kann das je nach Datenbank schon einen Unterschied machen, auf den man eben hinweisen sollte.

Was zum Unterschied zwischen diesen beiden Varianten halt noch beiträgt, ist z.B. bei MySQL auch die Version der Datenbank.
So wird erst ab Version 5.1.17 oder so auch für Prepared Statements ein Cache verwendet. Wie es bei anderen Datenbanken aussieht und wie weit die auch für Prepared Statements einen Query-Cache verwenden, weiß ich nicht.

Was bei Prepared Statements dann eben zu beachten ist und was der ein oder andere vielleicht nicht so beachtet, weil ihm das vielleicht nicht genau bewusst ist, wie Prepared Statements ablaufen: Führt man z.B. sehr oft eine Abfrage in einer Schleife aus, sollte man innerhalb der Schleife wirklich nur die Werte entsprechend anpassen und nicht immer die ganze Anfrage "vorbereiten" lassen. Das würde man dann nämlich schon recht schnell in der Geschwindigkeit merken.

Hier gibt es 2-3 Benchmarks dazu, aber halt mit sehr einfachen Abfragen: http://erlycoder.com/69/php-mysql-prepared-sql-statement-vs-sql-statement
Aber besonders den letzten Punkt kann man da schon recht gut bei "Elapsed time. SQL prepared each:" nachvollziehen, vor allem bei dem letzten Benchmark.





Schau mal bei meinem Projekt vorbei. Vielleicht ist das ja was für dich MyStartPanel - Deine persönliche Startseite mit deinen Favoriten
Auf der Suche nach einem guten Vokabeltrainer? Vokabeltrainer Cramfire - Schnell und effektiv Vokabeln lernen
27.08.2015, 12:33 Profil | PM | E-Mail  
Nicklas2751
Mitglied
Sehr guter User


Dabei seit: 19.02.2008
Herkunft: Bayern
Posts: 519
     OOP + Diagramme? Zitat | Bearbeiten

Wie sieht es denn mit allgemeinen Tipps & Tricks /Tutorials für die Softwareentwicklung aus? Z.B. beim Thema OOP könnte man das Thema UML und Klassendiagramme kurz anreißen und in den Tutorials dazu auch verwenden. Ich wäre natürlich auch bereit da dann was dazu zu steuern.


Über mich

----------------

18.09.2015, 13:43 Profil | PM | E-Mail  
asdf
Mitglied
Guter User


Dabei seit: 26.10.2009
Herkunft: keine Angabe
Posts: 420
      Zitat | Bearbeiten

Hallo Andavos

Wollte nur fragen ob dies noch aktuell ist? http://php-einfach.de/neu/ gibt nämlich nur ein 404 zurück!


03.11.2015, 19:47 Profil | PM | E-Mail  
Andavos
Administrator
Foren-Gott


Dabei seit: 30.11.2003
Herkunft:
Posts: 6274
      Zitat | Bearbeiten

Hi,
nein die aktuelle Adresse ist:
http://php-einfach.php-support.de/


Werde in einem ruhigen Moment die URL umziehen lassen, dann wird diese Variante normal unter php-einfach.de zu erreichen sein.


www.php-einfach.de, PHP lernen leicht gemacht
www.webhosterwissen.de, Webhosting-Vergleich



05.11.2015, 22:25 Profil | PM | E-Mail  
Gizmo
Mitglied
Gruenling


Dabei seit: 04.11.2015
Herkunft: keine Angabe
Posts: 17
      Zitat | Bearbeiten

Erstmal zu der neuen Seite, habs mir gerade angesehen: Ich finde sie sehr schick, wenn ich das so sagen darf.

Zitat:
ich bin noch unschlüssig ob MySQLi oder PDO, man müsste gucken was für Einsteiger am leichtesten verständlich ist. Irgendwelche Vorschläge?


Ich fänd's gut wenn es für beides Erklärungen/Tutorials geben würde. Hab erst vor kurzem angefangen hab mir bei euch die "Grundlagen" angeeignet und versuch mich nun weites gehend an OOP mit MySQLi. Hab mir auch mal PDO angeguckt aber auf den ersten Blick fand ich das noch zu kompliziert, insbesondere weil MySQLi mir im Zweifel immer noch die Möglichkeit gibt prozedural zu schreiben. Von daher denke ich wäre MySQLi für Anfänger wahrscheinlich am geeignetsten.

Aber es spricht ja auch nichts dagegen mehrere "Rubriken" bzw. Schwierigkeitsgrade einzurichten da kann ja dann jeder seinen Teil zu beisteuern und Neulinge profitieren umso mehr davon weil sie dadurch immer die Möglichkeit haben sich weiter zu entwickeln und sich neue/andere Sachen anzuschauen und zu lernen.

...da habt ihr die Meinung eines blutigen Anfängers.

P.S.: Danke, dass ihr euch hier soviel Mühe gebt. Ohne eure Seite wäre ich wahrscheinlich oft verzweifelt.


05.11.2015, 23:27 Profil | PM | E-Mail  
Andavos
Administrator
Foren-Gott


Dabei seit: 30.11.2003
Herkunft:
Posts: 6274
      Zitat | Bearbeiten

Weitere Erfahrungen zu PDO und MySQLi sind herzlich willkommen. Persönlich habe ich mich für PDO für die Tutorials entschieden. Am Anfang hat man vielleicht kurz mehr Probleme, aber danach fand ich es doch deutlich leichter als MySQLi.

Ein Crashkurs zu beiden ist aber vorhanden:
http://php-einfach.php-support.de/mysql-tutorial/crashkurs-mysqli/

http://php-einfach.php-support.de/mysql-tutorial/crashkurs-pdo/


www.php-einfach.de, PHP lernen leicht gemacht
www.webhosterwissen.de, Webhosting-Vergleich



06.11.2015, 00:02 Profil | PM | E-Mail  
Htaccess
Mitglied
Sehr guter User


Dabei seit: 22.08.2010
Herkunft: Deutschland
Posts: 703
      Zitat | Bearbeiten

Zitat:
Orginal von Gizmo
Ich fänd's gut wenn es für beides Erklärungen/Tutorials geben würde. Hab erst vor kurzem angefangen hab mir bei euch die "Grundlagen" angeeignet und versuch mich nun weites gehend an OOP mit MySQLi. Hab mir auch mal PDO angeguckt aber auf den ersten Blick fand ich das noch zu kompliziert, insbesondere weil MySQLi mir im Zweifel immer noch die Möglichkeit gibt prozedural zu schreiben. Von daher denke ich wäre MySQLi für Anfänger wahrscheinlich am geeignetsten.


Am Anfang ist immer alles schwer. Außer Mathe, das fällt einem in den Schoss. Spaß beiseite. Es mag kompliziert aussehen für den Anfang. Das ging vielen anderen genauso, aber wenn du erstmal PDO beherrschst, wirst du dankbar sein das es PDO gibt und verzichtest gerne auf MySQLi

Lieben Gruß,
Htaccess


16.11.2015, 13:56 Profil | PM | E-Mail  
Gizmo
Mitglied
Gruenling


Dabei seit: 04.11.2015
Herkunft: keine Angabe
Posts: 17
      Zitat | Bearbeiten

Zitat:
Am Anfang ist immer alles schwer. Außer Mathe, das fällt einem in den Schoss. Spaß beiseite. Es mag kompliziert aussehen für den Anfang. Das ging vielen anderen genauso, aber wenn du erstmal PDO beherrschst, wirst du dankbar sein das es PDO gibt und verzichtest gerne auf MySQLi

Lieben Gruß,
Htaccess


Das mag alles sein. Und hätte ich direkt ein richtiges Tutorial gefunden wo von Anfang an auf PDO und OOP eingegangen worden wäre und der Rest mehr oder weniger außen vor gelassen worden wäre, dann würde ich die Meinung bestimmt teilen.
Aber umgewöhnung ist (für mich jedenfalls) immer schwer.

Mein Vorschlag diesbezüglich wäre vielleicht, ein komplettes Step-By-Step Tutorial das aber die prozedurale Programmierung direkt weglässt bzw. nur minimal am Anfang kurz aufgezeigt wird.

Vor einigen Jahren wurde OO in PHP ja noch belächelt und niemand hat es richtig durchgezogen. Wenn ich mir heute die üblichen CMS, Forum, Gästebuch, ... Scrips angucke, dann sind die hingegen alle mittlerweile streng Objektorientiert angehaucht. Und PDO ist ebenfalls streng Objektorientiert. Von daher würde ich das zum Standard machen, meine Vorstellung wäre dann sowas wie ein Tutorial als roter Pfaden mit Ziel ein kleines Gästebuch.
Das ist nicht zu schwer und nicht zu leicht. Und man würde einen Großteil (wenn nicht sogar alle) Grundlagen lernen, die man benötigt um darauf aufbauend sich im Grunde alles zusammen zu basteln.

Nur meine persönlichen Bedenken sind halt: Es gibt genau sowas nicht, heißt: wenn ich jetzt was schreibe, muss ich mir jede Information mühevoll selber zusammensuchen.

Und je nachdem, wenn man weiter bei dem Prozeduralem Stil bleiben will, würde ich auch statt PDO eher MySQLi bevorzugen. Ansonsten ist PDO vielleicht sogar die bessere Möglichkeit.




17.11.2015, 01:25 Profil | PM | E-Mail  
Seiten (2):  1  2 
PHP-Support.de » PHP-Einfach » News » Relaunch PHP-Einfach.de   

Neues Thema | Antworten   


Powered by Command Board 1.0 - Beta 2.0 © 2004-08 PHP-Einfach | Impressum | Datenschutz