• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

MySQLi vs PDO

PDO oder MySQLi

  • Umfrageteilnehmer
    4
G

ge_fabian

Neues Mitglied
Hallo Leute ;)

man hat ja in letzter Zeit viel darüber gehört/gelesen, dass MySQL in PHP bald abgeschafft wird.

In der php.net Doku sieht man ja auch schon eindeutig, dass das stimmt, denn die mysql_* Extension ist als deprecated bezeichnet!

(http://de2.php.net/manual/en/function.mysql-query.php)

So und nun meine Frage: wie werdet ihr gehen, PDO, MySQLi oder vielleicht noch etwas ganz anderes?

Mich würde das echt mal interessieren, da ich momentan in meinem Projekt keine veralteten Techniken haben will, und es ja auch in neueren Versionen laufen soll!

(habe mal eine Umfrage hinzugefügt, mal sehen wie das funktioniert..)

Also wie geht ihr? Eure Meinung ist gefragt :D
 
Werbung:
Dass PHP MySQL abschaffen wird, glaube ich eher nicht. :D Ich glaube eher, dass sie Extension rausfliegen wird. :D

Ich denke, ich werde auf PDO umsteigen, da man damit noch flexibler ist.
 
ge_fabian schrieb:
man hat ja in letzter Zeit viel darüber gehört/gelesen, dass MySQL in PHP bald abgeschafft wird.

In der php.net Doku sieht man ja auch schon eindeutig, dass das stimmt, denn die mysql_* Extension ist als deprecated bezeichnet!
Zum Vergrößern anklicken....

Habe ich micht falsch ausgedrückt? :D
natürlich wird PHP nicht MySQL abschaffen! O:

Ich glaube aber auch das ich auf PDO umsteigen werde!

Wenn ich das richtig sehe ändert sich das SQL Statement nicht, oder sehe ich das falsch?
Es ändert sich doch nur die _query (mysql_query) und die _fetch sachen (bzw alle anderen Funktionen die PDO hat).

Also das eigentliche Statement bleibt doch, oder?
 
Werbung:
Ganz strikt gesehen, bin ich für keines der bedein. PDO hat mich aber von beiden Extensions bisher am wenigsten genervt.
Du kannst die Querys genauso benutzen, allerdings rate ich wirklich dazu, stattdessen prepared Statements zu benutzen, wenn du einem Query Parameter übergeben musst.
 
nun muss ich bald in meine mysql klasse pdo oder mysqli einbinden, um weiterhin die php standard konfiguration zu unterstützen... das ist der falsche weg. oop sollte als zusätzliche option für code design zur verfügung stehen.
 
OOP... Was du nicht sagst. OOP ist ein Paradigma nach dem man arbeitet. Man baut seine Applikation objektorientiert auf. Nur weil man Objekte benutzt, macht man noch lange keine OOP.
Du kannst Objekte auch ganz einfach prozedural anwenden und wenn dir diese Art zu arbeiten wirklich viiiiiiiiiiiiiel zu lästig wirst, kannst du die Objekte ja auch mit Funktionen wrappen.

Im Übrigen ist mysqli auch mit Funktionen und nicht nur als Objekt benutzbar:

PHP: 
$link = mysqli_connect();
mysqli_query($link, "select *");

Und wenn du schon "anderes" ankreuzt, sag uns doch, womit.
 
Werbung:
Mein Hoster steigt auf MariaDB um, an dem Quellcode muss ich also nix ändern (Umstieg von MySQL auf MariaDB) :)
 
Werbung:
Asterixus schrieb:
OOP... Was du nicht sagst. OOP ist ein Paradigma nach dem man arbeitet. Man baut seine Applikation objektorientiert auf. Nur weil man Objekte benutzt, macht man noch lange keine OOP.
Du kannst Objekte auch ganz einfach prozedural anwenden und wenn dir diese Art zu arbeiten wirklich viiiiiiiiiiiiiel zu lästig wirst, kannst du die Objekte ja auch mit Funktionen wrappen.

Im Übrigen ist mysqli auch mit Funktionen und nicht nur als Objekt benutzbar:

PHP: 
$link = mysqli_connect();
mysqli_query($link, "select *");

Und wenn du schon "anderes" ankreuzt, sag uns doch, womit.
Zum Vergrößern anklicken....


ich bleib bei der standard mysql extension. die funktioniert 1a. da ich selbst schon wrapper-funktionen angelegt habe kann ich die projekte immernoch auf mysqli ode dpo umstellen.. wär ne sache von max einer stunde.
den programmierstil von mysqli oder pdo find ich grausam und von prepared statements habe ich nur nachteile.
mich von den wrapperfunktionen der mysqli extension veräppeln zu lassen wär nen großer witz.

sichere prepared statements... wär nicht in der lage ist seine eingabewerte vorher zu prüfen soll steine hacken gehen...
seh schon den nächsten praktikanten hier im forum: wieso geht die nutzereingabe nicht in mein integerfeld in der datenbank... mysqli macht doch alles für mich.


edit:

wäre schade, wenn die hoster die mysql extension rausnehmen...der großteil der scripte die im umlauf sind würden dort nicht mehr funktionieren. daher geh ich davon aus, dass diese weiterhin verfügbar sein wird.
 
Zuletzt bearbeitet von einem Moderator:
Nur Nachteile? Man sieht, dass du einfach nur keine Ahnung hast. Warum ist der Stil grausam? Was für Nachteile? Du weißt aber schon, dass der Sinn hinter prepared Statements nicht hauptsächlich SQL-Injection-Abwehr ist? Die MySQL-Extension wird nicht weiterentwickelt, seit Jahren. Viele Features von MySQL 5.1 werden nicht unterstützt. Du hast gar keine Prepared Statements. Du kannst Stored Procedures nicht nativ benutzen. Es gibt keine multiple Statements. Transaktionen werden nativ nicht unterstützt, die muss man unsauber mir SQL-Statements erzwingen. Und außerdem ist es nun offiziell veraltet und wird abgeschafft werden.

Was nennst du veräppeln? Du wrappst doch selber MySQL (wie überhaupt?).
 
da muss ich mich wohl weiterbilden.^^

hab für die standard funktionen der mysql extension wrapper funktionen erstellt.
da könnt ich dann auch die pdo oder mysqli extension einsetzen. das was ich aus weiser vorrausicht gemacht habe ist in den meisten großen frameworks auch enthalten.
da kann einem der webspace anbieter keinen strich durch die rechnung machen und man ist an keine extension gebunden.

die dummheit die ich verteufel ist, dass die mysql extensions nun diese klassen ersetzen wollen. das ist aber garnicht notwendig. da ich weder 200 einzelne prekomplierte anfragen an eine datenbank senden möchte noch irgendwelche neuen funktion brauche und erst recht nicht einen ersatz für die bewährten mysql kassen, die millionen von entwicklern jetzt mal wieder den hintern retten werden. (muss man sich mal vorstellen... da spart man 25% rechenleistung fürs komplieren und macht dann hunderte einzelne anfragen aus der ganzen sache... alleine der grundgedanke dahinter macht mir gänsehaut)

die mysql extension ist nicht schlecht und funktioniert seit jahren sehr gut. falls diese extension dann doch mal nicht verfügbar sein sollte füg ich schweren herzens pdo, mysqli oder was auch immer dann grad verfügar ist ein.

mich interessiert die datenbank nicht die extension und solange die extension mein querys fachgerecht an die datenbank sendet passt das für mich. da ich größtenteils myisam nutze brauch ich auch keine vorgefertigten funktionen für transaktionen ;)



meine lieblingsfunktion ist diese hier, dafür brauch ich auch kein pdo:

Code: 
public function fetchAll() 
    {
        $return = array();
        if (is_resource($this->result))
        {
            while($row = mysql_fetch_array($this->result,MYSQL_ASSOC))
            {
                if(is_array($row))
                {
                    $return[] = $row;
                }
            }
            return $return;
        }
        return false;
    }
 
Werbung:
Glaub mir, PDO und mysqli haben keine Nachteile. PHP hätte sich schon längst von der MySQL-Extension trennen sollen. Ich bin glücklich, das die das nach drei Jahren hin und her endlich durchziehen. Das Problem ist nämlich, dass die MySQL-Extension eben nicht 1a funktioniert.
 
Hehe, und das fixen der mysql extension wäre nun das Monsterproblem gewesen?
Zum bestehenden Befehlssatz OOP Aufrufe hinzuzufügen (die Extension also zu erweitern) auch?
Nun haben wir alles Neu, mit neuen Befehlssätzen, der selben Funktionalität (prozedual kann man mit mysqli ja auch arbeite), und gefixten mysql Befehlen die man mit mysqli teilweise umgekehrt aufrufen muss. Super gemacht.....

Ich habe ja auch schon ein Thema dazu aufgemacht und ärgere mich darüber, dass die Syntax von mysql und mysqli nicht 1:1 übernommen wurde.
Mit sed durch hunderte Scripts zu fahren und aus mysql_ mysqli_ zu machen wäre ja kein Problem gewesen, aber Parameter in den Funktionsaufrufen zu tauschen ist schon etwas verwegen.

Ich betone!
Ich befürworte jede Erweiterung, jeden Bugfix und jede neue Funktion. Aber nicht so Laienhaft umgesetzt.

Ich habe für die alten Scripte auch einen Layer und Komplexes wird wohl (wie früher auch) mit PDO umgesetzt.
 
Werbung:
derMartin71 schrieb:
Naja, das war ja keine Fehlerliste, sondern nur fehlende Features ;) Ich bin jedenfalls froh, dass das endlich rausfliegt. So was sollten die konsequenter durchziehen. Auch wenn ich so gut wie gar kein PHP mehr verwende, nur noch für einige RESTful Webservices.

Gruß
/martin
Zum Vergrößern anklicken....
Was ist eigentlich mit den Entwicklern los?
KEINER hat bisher einen vernünftigen Grund nennen können, wieso das rausfliegen sollte.
mysqli bitet die selben Möglichkeiten wie mysql und mehr.

Über das Mehr braucht man nicht reden, ist eine tolle Sache. Wieso mysqli nicht als weiteres Zusatzmodul mit allen seinen zusätzlichen Möglichkeiten angeboten wird und was daran unvernünftig sein soll begründet keiner.

Ich lese hier nur Meinungen und Bauchentscheidungen, keine logischen Argumente. Weiters bezweifle ich, dass sich irgend wer mit der Wartung der Extensions mal näher beschäftigt hat.

Die Wartung von mysqli wäre mit Sicherheit wesentlich einfacher würde man die neuen Funktionen von den bewährten trennen. Kritische Fehler werden sich wohl eher in den neuen Funktionen finden als in den bereits seit Jahren vorhandenen. Ich bin gespannt, wieviele Sicherheitspatches es zu mysqli nach der endgülltigen Umstellung geben wird und vor allem, wo die Lücken zu finden sein werden.
Abgesehen davon würde man Server skalierbarer und sicherer machen, wenn man die mysqli-Extension nicht laden müsste, bräuchte man sie nicht, ähnlich der gd oder imap oder ldap extension, die man auch nur läd, wenn man sie braucht.

Weiters wird es wohl in Zukunft eine eigene externe PHP-Extension geben, die mariadb unterstützt, was ebenfalls Sicherheitsprobleme schaffen wird.

mysql_select_db($dbname, $link ) und mysqli_select_db($link, $dbname) sind vollkommen indent, nur die Parameter wurden umgedreht. Sogar der Code in der Extension ist nahezu der selbe (man greift also durchaus auf altbewährtes zurück). Und wenn man sucht, stösst man auf mehrere solcher Beispiele.

Wo also ist denn nun die Verbesserung (exclusive des Mehr, was man wie gesagt als weitere Extension anbieten könnte)?
 
Zuletzt bearbeitet von einem Moderator:
Werbung:
Für Standardabfragen mag die MySQL-Extension reichen, aber seit mehreren Jahren ist die MySQL-Extension eine Last für das PHP-Enticklerteam.
ext/mysql is hard to maintain code. It is not not getting new features. Keeping it up to date for working with new versions of libmysql or mysqlnd versions is work, we probably could spend that time better.
Zum Vergrößern anklicken....
Neben diesem Aspekt und der Tatsache, dass PDO und mysqli eine bessere Unterstützung für die Funktionalitäten als MySQL haben, soll anscheinend auch ein Sicherheitsproblem bei der Benutzung von MySQL bestehen. Inwiefern das genau der Fall ist, habe ich nicht recherchiert, aber ich nehme doch an, dass das PHP-Team nicht falsche Sicherheitslöcher einräumt, nur um sich von einer Altlast wie MySQL zu befreien.

Wenn man nämlich deiner Argumentation folgt, müsste PHP auch noch PHP4 unterstützen und bugfixen. Schließlich ist es noch benutzbar.
 
ich gehe stark davon aus, dass php aus marketing gründen die neuen extensions für sicherer erklärt.
mein stand ist, dass diese vermeindlichen sicherheitsvorteile von den sicheren prepared statements herrühren. sehe das ehr als nachteil und bevormundung. eine reaktion auf die vielen fachlich inkompetenten menschen, die mit php arbeiten wollen. selbes schema wie bei ruby on rails, marketing für fachfremde.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben