nicht angemeldet
Hi!
Du meinst, es ist reichlich überflüssig, diesen einen zusätzlichen Buchstaben zu tippen, nur weil man den auch weglassen kann?
Es geht mir nicht um diesen einen Buchstaben sondern um die Komplexität, die das mysqli mitbringt und damit auch die möglichen Wege zur Lösung und die dabei vorhandenen potentiellen Fehlerquellen.
Es wird seinen Grund haben, warum man die zusätzlichen Features nicht in die mysql-Extension hineingetan hat, sondern eine eigenständige Extension programmierte. Und es ist zu vermuten, dass mysql irgendwann als Feature nicht weiter entwickelt wird, also auf die Abschussliste kommt.
Das sehe ich als unrealistisch an, weil damit jede Menge vorhandener Code unbrauchbar gemacht wird. So unklug sind die PHP-Entwickler nun auch wieder nicht. Wenn es so weit kommen sollte, so wird das garantiert rechtzeitig genug bekannt gegeben. Wenn ich mir die PHP-6-Entwicklung ansehe, wird man Jahre Zeit haben, den Umstieg vorzubereiten und zu propagieren.
MySQLi erlaubt, ausweislich der Dokumentation, den Zugriff auf Features von MySQL ab Version 4.1. Das ist schon eine extrem alte MySQL-Version. Es gibt eigentlich keinen Grund, auf diese Features schon direkt im Programmcode zu verzichten, indem man grundsätzlich die falsche Extension einsetzt.
Verstehe auch nicht, wieso du plötzlich genau in diese Richtung argumentierst.
Es ist kein plötzlich. Mein Prinzip ist nicht, nur weil etwas da ist, muss man es verwenden, sondern darüber nachzudenken, ob einem die Verwendung Vorteile, Nachteile oder überhaupt nichts bringt. Ich sehe für mysql vs. mysqli einfach keinen Grund, warum ich gegen das Bewährte argumentieren soll, nur weil es was neues (in diesem Fall wegen des gleichen Unterbaus nur was erweitertes) gibt, mit mehr Features, die weder angewendet werden sollen noch verstanden werden.
Welche Features sind es denn, die für 0815-Anwendungen interessant sein könnten?
-
Multiquerys?
Selten. Und wenn, dann muss man sich mit einem komplexen Ergebnisabholungsprozess rumschlagen. -
Stored Procedures?
Es fällt ja vielen schon schwer, normale Statements zu formulieren. -
Prepared Statements?
Haben eine meiner Meinung nach recht ungewöhnliche Umsetzung, wie man Variablen binden muss. Dieses Konzept muss man auch erst einmal verstehen. Und es schränkt insoweit ein, als dass man jede Variable (inklusive einzelne Array-Elemente) einzeln angeben muss und nicht Arrays übergeben kann. P.S. sind auch für Massendateneinfügungen vorgesehen. Doch man kann keine Zeilen-Arrays an das Execute übergeben (oder vorher binden) (geschweige denn, ein Array mit Zeilenarays einem einzigen Execute-Aufruf übergeben). Man muss das Werte aus dem Array vor dem Execute erst noch auf die gebundenen Variablen kopieren. Zudem wird das Ergebnis auch in einzelnen Variablen geliefert und nicht gebündelt als Array/Objekt, um es gemäß EVA-Prinzip später verwenden zu können. Sicher kann man hier mit Hilfe der SPL und einem Iterator ein Array simulieren - zum Preis weiterer Komplexität. Sinnvoll, wenn man es braucht, aber nicht pauschal. - Ich könnte mitgehen, wenn man PDO propagiert, denn da ist das P.S.-Handling wesentlich benutzerfreundlicher implementiert. - Sicherheit? Ist eine nette Nebenwirkung, aber nicht der primäre Zweck. Man erkauft sie sich mit der erhöhten Komplexität des P.S.-Handlings.
Wie gesagt, das sind (abgesehen von der Implementierung) alles wunderbare Features an sich - für den der sich braucht. Und ich werden einen Teufel tun, sie jemandem auszureden, wenn er sich dafür entschieden hat, wenn er Bedarf dazu hat, und wenn die Vorteile die Nachteile bei ihrer Verwendung - konkret für den Einsatzzweck beurteilt - überwiegen. Für eine pauschale Empfehlung habe ich jedoch nicht genügend stichhaltige Argumente.
Lo!