MySQLi vs PDO
- Ersteller ge_fabian
- Erstellt am
derMartin71
Neues Mitglied
Es steht Dir doch frei, PHP nach Deinem Gusto selber zu kompilieren und nur die Module zu laden, die Du auch benötigst. Gerade bei größeren Portalen, die PHP benutzen, wird das so gemacht. Wobei die Skalierbarkeit weniger an PHP, sondern eher am verwendeten WebServer liegt. Da hat sich gerade in den letzten Jahren der Apache zum Bottleneck entwickelt.
Gruß
/martin
F
FoXMorayn
Guest
marketing könnte hier bedeuten:
- einen ruby on rails entwickler zu php zu locken
- dem wirtschafter nahe zu legen expizit nach einer entwicklung in php zu fragen
- mysql unattraktiv erscheinen zu lassen, um den wechsel zu beschleunigen
ähm eginx?^^ bin ich auch gegen ;)
- einen ruby on rails entwickler zu php zu locken
- dem wirtschafter nahe zu legen expizit nach einer entwicklung in php zu fragen
- mysql unattraktiv erscheinen zu lassen, um den wechsel zu beschleunigen
ähm eginx?^^ bin ich auch gegen ;)
S
sysop
Guest
Was mich stark an die Begründung erinnert, warum nautilus als Dateimanager aus Gnome3 geflogen ist.
Sinngemäss:
Die scheinbar eifachere Wartung von mysqli scheint mir angesichts des fast indenten Codes von mysql und mysqli für prozeduale Abfragen an den Haaren herbeigezogen und als Blabla-Argument für Unwissende mal eben in den Raum geworfen.
Man will mir doch nicht weissmachen, dass der Tausch von Funktionsparametern gepaart mit einem anderen Funktionsnamen das Warten erleichtert. Dafür mache ich das Geschäft schon zu lange.
By the way:
Ich erinnere mich momentan an keinen Fall, wo durch ein Update die mysql-Extension aus Wartungs oder Sicherheits-Gründen getauscht wurde. 99% der Sicherheitsfehler werden über den mysql-Engine gewartet, da mysql den eigentlichen Bug enthällt.
Meine letzte Server-Installation war im August vorigen Jahres und ALLE Updates sind eingespielt, der Datumsstempel der mysql.so liegt beim 6 August Zeitgleich mit der mysqli Extension! Die letzten php5-mysql Updates sind vom Mai und Juni und haben ausnahmslos sicherheitskritische mysqli Wartungen.
derMartin71
Neues Mitglied
Öhm ...
Im "professionellen" Umfeld wird doch eh nur nach Leuten gesucht, die sich mit Frameworks auskennen (Zend Framework, Symfonie usw.). Und da stellt sich nicht die Frage nach mysql, mysqli oder PDO ... da geht's um CRUD.
Es geht auch nicht darum, das DBM im Hintergrund als unattraktiv erscheinen zu lassen, eher im Gegenteil. Die Unattraktivität kommt doch nur von der alten Mysql Extension, da die Datenbankfeatures, die Heutzutage als "Fancy" bezeichnet werden, nicht unterstützt sind.
Gruß
/martin
F
FoXMorayn
Guest
ich geb dir recht, dass eine neue extension mit features werbewirksamer ist, und dass es im entscheidenden bereich ehr auf größere marken wie zend ankommt.
trotzdem seh ich die aussage zur sicherheit ehr als einen witz und als reines marketing gezuppel an.
[ot]
achja..^^ zend-framework bin ich auch gegen. die letzte vorstellung von dem framework hab ich letztes jahr gesehen, dort schien es immernoch unvollständig. der rechenfehler, der magento so berühmt gemacht hat (cent rechenfehler im warenkorb), hat mir eh schon den rest gegeben. glaub das framework hat letztes jahr nochmal negative schlagzeilen in verbindung mit dem shopsystem gemacht.
profressionelle entwicklung ist sicherlich nicht an bekannte frameworks gebunden.
[/ot]
trotzdem seh ich die aussage zur sicherheit ehr als einen witz und als reines marketing gezuppel an.
[ot]
achja..^^ zend-framework bin ich auch gegen. die letzte vorstellung von dem framework hab ich letztes jahr gesehen, dort schien es immernoch unvollständig. der rechenfehler, der magento so berühmt gemacht hat (cent rechenfehler im warenkorb), hat mir eh schon den rest gegeben. glaub das framework hat letztes jahr nochmal negative schlagzeilen in verbindung mit dem shopsystem gemacht.
profressionelle entwicklung ist sicherlich nicht an bekannte frameworks gebunden.
[/ot]
derMartin71
Neues Mitglied
Aha .. und was lässt Dich vermuten, dass das nicht einfach das Datum des Erstellens der Distro, bzw. das Compile Datum der Extension ist?
An Deiner Stelle, wäre ich mit solchen Aussagen vorsichtig ...
derMartin71
Neues Mitglied
Deswegen hatte ich ja professionell in Anführungszeichen gesetzt. Fakt ist aber, das genau diese Leute gesucht werden. Ist wie bei Frontend-Entwicklern, da kommt es "leider" nicht auf die Javascriptskills an, sondern, wieviele Frameworks und Libraries man kennt. Leider haben die meisten davon, einfach zu wenig Ahnung von der Sprache Javascript selbst (Variablen Scope, Firstclass Functions ...)
Achja, ich weiß jetzt wo Du überall "dagegen" bist, wo bist Du denn dafür? ;)
Gruß
/martin
F
FoXMorayn
Guest
für mehr fahrräder und weniger autos.
für drei-schichten-architektur und dem gewissenhaften umgang mit variablen, kontextwechseln und dem einsatz von datentypen und ganz klasse wär ein PHP: filter_var - Manual in verbindung mit der mysql extension. auch absolut pro verbindungen mit objekten zu lösen, das war längst überfällig.
und ganz besonders bin ich dafür sich nicht von irgendwelchen hypes blenden zu lassen. facebook, whatsapp, studivz, ruby on rails, html5 webapp, nginx usw usw. mach das alles gerne mit und schau mir alles mal an, aber für den produktiven einsatz dann doch bitte etwas das grund solide ist.
für drei-schichten-architektur und dem gewissenhaften umgang mit variablen, kontextwechseln und dem einsatz von datentypen und ganz klasse wär ein PHP: filter_var - Manual in verbindung mit der mysql extension. auch absolut pro verbindungen mit objekten zu lösen, das war längst überfällig.
und ganz besonders bin ich dafür sich nicht von irgendwelchen hypes blenden zu lassen. facebook, whatsapp, studivz, ruby on rails, html5 webapp, nginx usw usw. mach das alles gerne mit und schau mir alles mal an, aber für den produktiven einsatz dann doch bitte etwas das grund solide ist.
F
FoXMorayn
Guest
meine glaskugel sagt mir folgendes vorraus
PHP:
<input type="date" name="date">
<?php
$stmt = $dbh->prepare("INSERT INTO tbl_name (col1) VALUES(:date)");
$stmt->bindParam(':date', $date);
// eine Zeile abfragen
$date = $_POST['date'];
$stmt->execute();
?>
F
FoXMorayn
Guest
du räumst das forum noch leer ;)
derMartin71
Neues Mitglied
Also zu Pkt.1 kann ich auch nur zustimmen ;)
Zum Rest fällt mir nur ein "Was der Bauer nicht kennt, frisst er nicht" ... Das Web hat sich in den letzten Jahren einfach weiterentwickelt (und das ist auch gut so). Dem entsprechend haben sich die Anforderungen an Server und Client grundlegend geändert. Und das "grund solide" ist in vielen Fällen einfach nicht mehr zeitgemäß. Drei- oder gar Vier-Schichten lassen sich nur mit erheblichen Aufwand, skalieren, warten usw. Zu nginx, das Teil ist grund solide und macht genau das, was es soll ... Seiten ausliefern und das schnell, nicht mehr und nicht weniger. Apache ist mittlerweile in vielen Fällen, mit Kanonen auf Spatzen schießen.
S
sysop
Guest
Man hat das Rad nicht neu erfunden, zumal die API von mysql relativ genaue Vorgaben enthhällt. Die Aufbereitung und Übergabe der Ergebnisse an PHP kann sich nicht so geändert haben.
was soll sich von
PHP:
mysql_select_db($dbname, $link)
PHP:
mysqli_select_db($link, $dbname)Genau da setzt mein Gedanke und meine Kritik an. Eine neue Extension mysqli, die nur die erweiterten Möglichkeiten bietet (und z.B. auf prozeduale Programmierung verzichtet) und sicherstellt, dass alte Scripte mit den mysql-Befehlen weiterhin laufen wäre sicher zu begrüssen. Von mir aus auch eine mysqli-Erweiterung, die die Funktionalität der alten Aufrufe sicherstellt. Den Layer habe ich mir nun ja auch selbst gebaut und er funktioniert perfekt.
Ich nutze für sehr grosse Projekte z.B. seit längerem PDO (ehemals PECL), was ja auch als zusätzliches Feature zu PHP hinzugefügt wurde (ich glaube seit PHP5 oder 5.1). Eine ähnliche Vorgangsweise hätte ich mir für mysqli auch gewünscht.
Keine Ahnung, wieviele Firmen sich einen Webauftritt haben schreiben lassen, der auf mysql basiert und auf die nun weitere Kosten zukommen, weil sie alles überarbeiten lassen müssen.
Die Syntax dahingehend zu ändern, dass ein einfaches Suchen/Ersetzen NICHT funktionieren wird kritisiere ich, da Projekte die auf simplen Abfrage basieren nicht mal eben umgearbeitet werden können und die Unterstützung für einige simple Anweisung (wohlgemerkt für einfache Projekte) komplett entfallen ist (Bsp: mysql_field_name($result, $offset) wird duch mysqli_fetch_field_direct($result, $offset) ersetzt und muss zusätzlich mit $field_name->name abgefragt werden ). Meine Kritik richtet sich insbesondere deshalb gegen die Syntax , da die Parameterübergabe in 95% der Fälle nur getauscht und nicht durch andere notwendige Parameter erweitert wurde. mysqli unterscheidet sich also für simple Aufrufe von mysql in genau garnichts, ausser der Namensgebung und des Parametertausches. Was da im Hintergrund abläuft ist mir persönlich vollkommen egal.
Eine detaillierte Aufzählung spare ich mir (da sowieso alle die hier diskutieren, wissen was ich meine (hoffentlich), reiche ich aber auch gerne nach.
NICHT mysqli mit all seinen Funktionen steht im Mittelpunkt meiner Kritik, sondern die Art wie hier ausgetauscht wurde. Meine Existenz als Entwickler mag mit den Umbauarbeiten gesichert sein, aber ich kann mich leider nicht um Neues kümmern, was ich als viel reizvoller betrachte.
Das ist einfach. Indem ich einfach mal zum Spass die history-Files der Updates auf älteren Servern (laufen schon seit mehreren Jahren) "durchgegrept" habe. Letzte Änderung des php5-mysql Paketes war im Mai und im Juni und wurde durch Updates erneuert. Weshalb es Updates gab lässt sich mit google b.z.w durch entsprechende Sicherheitshinweise einschlägiger Webadmin-Dienste ermitteln. Es war jedenfalls nicht die Extension mysql verantwortlich.
Bitte nicht aus dem Zusammenhang reissen. mysqli muss genauso gewartet werden wie mysql. Einen Mehraufwand sehe ich da beim besten Willen nicht, zumal die mysqli-Extension nun neben den simplen prozedualen Aufrufen auch noch die OOP Aufrufe zu warten hat.
Indem man beide Verwendungsarten in die selbe Extension gepackt hat, kann der Aufwand nur ein höherer sein, es sei denn man hat sie streng voneinander getrennt. Wäre dem so, würde das nur für meine Argumentation getrennter Extensions sprechen. ist dem nicht so, hat jede Änderung eines mysqli_select_db() erhebliche Auswirkungen auf die gesamte Extension. Fehler, die also in den Aufruf gebaut werden, wirkten sich direkt auch auf new mysqli(); aus.
Ich betone mal:
Ich finde Neuerungen sehr sehr cool, muss aber keinen Zusatzaufwand haben, den man leicht hätte umgehen können.
So nun lasse ich das mit den langen Arien hier
Zuletzt bearbeitet von einem Moderator:
Asterixus
Aktives Mitglied
Du weißt aber schon, warum mysqlis API die Reihenfolge der Parameter gewechselt hat? Ganz einfach weil die globale Verfügbarkeit über die Verbindung im ganzen Script eigentlich nicht natürlich ist. Man sollte die Resource den nötigen Funktionen übergeben müssen.
Und find/replace funktioniert sehr wohl, wenn man ein bisschen überlegt. Man kann nämlich die mysqli-Funktionen wrappen, damit die Reihenfolge der Parameter gleich ist und man kann sogar die Unsauberkeit der MySQL-Extension weiterhin unterstützen, indem man sogar den Resource-Parameter optional mach und ihn statisch irgendwo ablegt.
Nicht benutzen, das ist unsauber.
Und find/replace funktioniert sehr wohl, wenn man ein bisschen überlegt. Man kann nämlich die mysqli-Funktionen wrappen, damit die Reihenfolge der Parameter gleich ist und man kann sogar die Unsauberkeit der MySQL-Extension weiterhin unterstützen, indem man sogar den Resource-Parameter optional mach und ihn statisch irgendwo ablegt.
PHP:
$GLOBALS["mysqli"] = mysqli_connect();
function my_query($sql, mysqli $result = null) {
if ($result === null && isset($GLOBALS["mysqli"]) && $GLOBALS["mysqli"] instanceof mysqli) {
$result = $GLOBALS["mysqli"];
}
if ($result === null) {
throw new Eception("Not connected");
}
return mysqli_query($result, $sql);
}Nicht benutzen, das ist unsauber.
derMartin71
Neues Mitglied
Die letze Änderung an der MySQL Extension wurde für PHP 5.3.19 gemacht. Den Grund dafür haben wir in einem anderen Thread schonmal diskutiert. Und genau da zeigt sich ja, das man sich von Altlasten einfach mal trennen sollte, wenn es dafür einen besseren Ersatz gibt.
- Fixed compilation failure on mixed 32/64 bit systems.
Zuletzt bearbeitet:
S
sysop
Guest
Hi
Ich wrappe ja auch, finde das aber wesentlich unsauberer, als eine native Unterstützung seitens des Moduls. Nichts anderes habe ich oben geschrieben.
Aber zugegeben, ich habe mal wieder ein Traktat verfasst.....
@derMartin71
Ich habe nichts gegen die Trennung an und für sich, die Umsetzung erzeugt hier Wartungstraffic, den ich nicht begrüsse, weil er mich bindet, wo ich nicht gebunden sein sollte.
Meine Motive der Kritik sind nicht rein technischer Natur, das gebe ich gerne zu.
Wie ich in Zukunft Projekte erstelle ist mir relativ egal. Die Umstellung wurde ohne jede Rücksicht auf bestehende, laufende Projekte gemacht.
Ich wrappe ja auch, finde das aber wesentlich unsauberer, als eine native Unterstützung seitens des Moduls. Nichts anderes habe ich oben geschrieben.
Aber zugegeben, ich habe mal wieder ein Traktat verfasst.....
@derMartin71
Ich habe nichts gegen die Trennung an und für sich, die Umsetzung erzeugt hier Wartungstraffic, den ich nicht begrüsse, weil er mich bindet, wo ich nicht gebunden sein sollte.
Meine Motive der Kritik sind nicht rein technischer Natur, das gebe ich gerne zu.
Wie ich in Zukunft Projekte erstelle ist mir relativ egal. Die Umstellung wurde ohne jede Rücksicht auf bestehende, laufende Projekte gemacht.
Asterixus
Aktives Mitglied
Es wurde lange genug darüber informiert (2 Jahre) und die Leute haben noch zwei Jahre bis die Hoster PHP5.5 auch wirklich anfangen zu benutzen. Man kann nicht ewig um Abwärtskompatibilität beizubehalten, Altlasten mit sich schleppen.
Weitaus mehr Ärger wird die Verlaterung des /e-Modifiers in PCRE bereiten über die niemand spricht
Weitaus mehr Ärger wird die Verlaterung des /e-Modifiers in PCRE bereiten über die niemand spricht
