Hat schon jemand damit Erfahrungen sammeln können?

Wie ich das verstehe, ist das damit die vierte API wie man nun von PHP5
auf MySQL Datenbanken zugreifen kann. Es benötigt offenbar keine MySQL Clientslibs mehr sondern dockt direkt am Server an (MySQLi). Nur mussman sich wohl fragen ob Dinge wie PDO dann überhaupt noch Sinn machen, denn
Mysqlnd geht derart PHP und MySQL spezifische Wege das Pro PDO Argumente
schwierig werden. Ein PDO Modus wird wohl unterstützt, ist aber eher eine Art Alibifeature.

Mysqlnd ist ab PHP 5.3 fest integrierter Bestandteil von PHP und kann für jede Datenbank ab MySQL 4.1 aufwärts eingesetzt werden (Hinweis: MySQL 4 ist out of Support). Allenfalls wenn man PHP 5.3 selbst kompiliert, kann man den Mysqlnd-Support aus PHP 5.3 entfernen, was jedoch sicher nicht viele machen werden, denn gerade das Thema Performance, Memory,CPU-Cost,Bandwich per Cycle sind und bleiben kritisch beäugte Themen für die overall Websiteperformance.

Quelle:
http://blog.felho.hu/what-is-new-in-...3-mysqlnd.html

[robo47]

http://developers.sun.com/databases/...ysql_php4.html

That is, from PHP 5.3 onwards the developer can choose between libmysql and mysqlnd when using ext/mysql, ext/mysqli, or PDO extensions to connect to the MySQL server 4.1 or newer.

Klingt für mich so als ob das ne Ebene unter den normalen funktionen ansetzt und damit kein Ersatz für pdo oder ähnliches ist, sondern pdo/mysql_* und mysqli_* diese Funktionen dann intern nutzen können anstatt der normalen mysqllib, im endeffekt dürfte sich für den Benutzer also kein wirklicher unterschied ergeben ausser dass es resourcen-ärmer und schneller wird.

Find ich das gut wenn etwas schneller und resourcenschonender wird :)

Naja, das dachte ich anfangs auch, aber im Detail schaut es wohl doch anders aus:

Mysqlnd (Native Driver) is highly integrated with the Zend engine, so it can leverage all the internal PHP infrastructure for communication and memory management, it can do a lot of tricky thing to improve performance.

http://blog.felho.hu/what-is-new-in-...3-mysqlnd.html

Da ist eine Grafik, die zeigt wo mysqlnd intregriert ist. Ich denke damit ist klar das es mit PDO an der Stelle nichts werden wird. Für PDO müsste der Treiber ja ein PDO konformes Interface bieten, das dann aber wieder nur eine Untermenge der Treiberfunktionalität erschießen würde. Mysqlnd ist aber kein PDO Treiber, müsste also zu einer Art hybriden werden (was wohl nicht angestrebt ist) Es existiert offebar aber so etwas wie eine mysqld to PDO-Driver Bridge.Der Profi wird dann wohl eher dazu neigen PDO für MySQL =>
5 + PHP5 => 5.3 auszumustern (zumindest wenn MySQL als DB zum Einsatz kommt). Es spricht halt auch viel für Mysqlnd, weil es eben PHP5.3 und höher und MySQL so eng verbindet wie nichts anderes und die Performance dementsprechend ist.

Update, ich habe das noch etwas gefunden:

*
Technisch gesehen kann heutzutage entweder via ext/mysql, ext/mysqli oder PDO/MySQL mit PHP auf MySQL-Datenbankserver zugegriffen werden

*
Dennoch hat Kai Arnö jetzt einen weiteren Treiber angekündigt, der nativ in PHP integriert sein und PHP's interne Infrastruktur wie Strings, Zend Memory Management, PHP Streams (Virtual I/O), Hashes, Lists Thread Safe Resource Manager, ZLIB, SSL, Crypt, ... nutzen wird, und somit auch Performance- und Anwendungsverbesserungen verspricht (Mysqlnd)

*
Für PHP-Programmierer, die die bisherigen Extensions nutzen, wird sich nichts ändern, außer dass für ext/mysqli und PDO/MySQL mit mysqlnd neben libmysql eine weitere, besser integrierte Alternative für die Verbindung mit MySQL zur Verfügung stehen wird

Das heißt wohl, wenn Du PDO willst, musst Du auf Mysqlnd verzichten. Ist irgendwie blöd,
hat aber Performancetechnisch gesehen wohl vorteile. Die meisten Leute setzen PHP ja auch nun mal mit MySQL ein, da kann ich den Wunsch dieser großen Interessengruppe auch irgendwie nachvollziehen.

http://www.dynamic-webpages.de/02.news.php?time=11.2006

[robo47]

Wenn man sich den Blogeintrag anschaut entdeckt man ja auch nirgends funktionsnamen die auf eine komplett neue Erweiterung schließen lassen, keine mysqlnd_*-funktionen, keine Klasse mit dem Namen oder ähnliches, die beispiele für neue funktionen haben das mysqli_-prefix

Der Eintrag ist von ... Ende 2007 ? Wohl nicht mehr ganz up2date
-> http://blog.ulf-wendel.de/?p=166

http://dev.mysql.com/downloads/connector/php-mysqlnd/

The MySQL native driver for PHP is an additional, alternative way to connect from PHP 5.3 or newer to the MySQL Server 4.1 or newer. It is a replacement for the libmysql, the MySQL Client Library. As of PHP 5.3 you can use ext/mysql, ext/mysqli and PDO_MYSQL either together with libmysql as you did in the past or with mysqlnd.

Und im Q/A Teil steht ja auch ganz deutlich dass es eben keine neue Extension ist, sondern eben nur ein Treiber

Mysqlnd ist aber kein PDO Treiber, müsste also zu einer Art hybriden werden (was wohl nicht angestrebt ist)

abhängig davon ob ich mein php mit libmysql oder mysqlnd compiliere werden in dem PDO_MYSQL-Treiber dann halt andere funktionen genutzt,, sprich eine andere im Implementierung für PDO_MYSQL, die Schnittstelle bleibt gleich, aber intern wird mit anderen funktionen gearbeitet, da sehe ich nicht wirklich ein Problem.

sprich eine andere im Implementierung für PDO_MYSQL, die Schnittstelle bleibt gleich, aber intern wird mit anderen funktionen gearbeitet, da sehe ich nicht wirklich ein Problem.

Ja, vermutlich hast Du recht. Ich habe mal bei MySQL Forge geschaut und
da steht jetzt das:

As of PHP 5.3 all PHP extensions using MySQL (ext/mysql, ext/mysqli, PDO_MYSQL) use mysqlnd as a default.

*
The MySQL native driver (mysqlnd) for PHP is an optimized drop-in replacement for the MySQL client library (libmysql).

*
The MySQL native driver for PHP has proven its compatibility, stability and excellent performance as an optional backend library of the MySQL flagship PHP Connector ext/mysqli.

*
As of PHP 5.3 all PHP extensions using MySQL (ext/mysql, ext/mysqli, PDO_MYSQL) use mysqlnd as a default

Das war jetzt aber eine schwere Geburt Der eine schreibt dies, der andere
das, da weiß man gar nicht was man glauben soll. Aber so ist es mir auch am liebsten. Nur verstehe ich dann irgendwie nicht, wie das jetzt dann noch so dicht mitz PHP5 verzahnt sein soll z.B Stichwort "nutzt den gleichen Memeorymanager u.s.w"). Naja, vielleicht haben sie sich das irgendwann mal anders überlegt.

[robo47]

Zitat von marc9022

Nur verstehe ich dann irgendwie nicht, wie das jetzt dann noch so dicht mitz PHP5 verzahnt sein soll z.B Stichwort "nutzt den gleichen Memeorymanager u.s.w"). Naja, vielleicht haben sie sich das irgendwann mal anders überlegt.

mysqllib ist eine frei nutzbare Implementierung die von diversen anderen Programmiersprachen die mysql nutzen auf C-Ebene auch genutzt wird für deren Implementierungen, die hat quasi keine Abhängigkeiten/ist stand-alone lauffähig, mysqlnd ist jetzt aber direkt für php gebaut, benutzt Dinge aus dem Core von php und ist somit nicht einfach in einer anderen Sprache nutzbar, sprich der overhead dass die mysqllib gewisse sachen selbst implementiert die der PHP-Core auch bietet, fällt weg.

Das wusste ich schon. Aber das erklärt immer noch nicht die Aussage das z.B mysqlnd und Zend Engine sich so nah sind, daß z.B mysqlnd das Zend Engine Speichermanagement nutzt u.s.w. Das hört sich für mich nicht eben nach einem libmysql replacement aus. Aber naja, diese Definition war auch älter,
vielleicht haben sie es sich irgendwann anders überlegt.Oder gibt es noch einen anderen Deutungskontext der mir bisher entgangen ist?

[robo47]

Ich finde jetzt das erklärt es schon, mysqlnd wurde ja direkt für PHP entwickelt und nutzt anstatt selbst Code für Speichermanagement vorzuweißen eben die Zend Engine.
Dabei kann es aber ja trotzdem nach außen hin die gleichen schnittstellen abdecken wie vorher libmysql.

Das ist ja das schöne unabhängig der Programmiersprache, wenn man eine Komponente ordentlich gekapselt hat, keine Abhängigkeiten hat, kann man sie jederzeit austauschen solange die neue Komponente die gleiche Schnittstelle hat bzw. in dem Fall direkt so programmiert wurde dass sie die alte Schnittstelle mitbringt.
Und selbst wenn man die Schnittstelle nicht ganz einhält, da es ja jetzt eine für ein spezielles System geschriebene Komponente ist, kann man ja bei den anderen Komponenten die die neue Komponente nutzen sollen schauen inwieweit man da auf eine andere Schnittstelle umstellt, bzw. was man umbaut um das gesammte effizienter zu gestalten. In dem Fall hat man sich also "nur" mysql_, mysqli_ und pdo_mysql anschauen müssen und dort noch eventuelle Änderungen machen.

Ich habe mir mal PHP 5.3 gezogen und damit herumgespielt, ist ja schon Release Candidate und dort ist mysqlnd ja schon standardmässig voreingestellt. Ich meine schon das die Queries subjektiv berachtet geringfügig schneller und die Error oder Resultfeedbacks rascher zurück kommen. Habe es nun nicht gemessen, kommt mir aber so vor. Was ich mir auch mal wünschen würde ist, das es ein einheitlichen Singleton für
Datenbanken geben sollte. Klar kann ich das selber machen, schicker wäre es
aber wie z.B mit Apache DBCP unter Tomcat. Da schreibe ich die Parameter
in eine XML-Datei die im Root Verzeichnis liegt und kann dann darauf
zugreifen. Ich glaube ZendFramework bietet zwar auch so einen Mechanismus,
die machen es jedoch über eine INI-Datei. MS .NET und Java Servlet sind
was das betrifft hier schon lange Vorbild. Nur MS .NET geht hier noch einen
Schritt weiter und ermöglicht es sogar die Cleartext Config Files zu verschlüsseln damit Kennwort und Username nicht so einfach für externe
ersichtlich sind.

[robo47]

Jenachdem was genau du gerne als Singleton hättest würde ich da wohl widersprechen, weil sobald man vielleicht mal mehr als eine Datenbank parrallel nutzen will, steht man mit nem Singleton immer dumm da.

Im Zend Framework läuft viel über Configs die man wahlweise aus .ini-Dateien, php-arrays und auch aus .xml-Dateien erstellen kann.
Einen Singleton für die Datenbank gibt es im Zend_Framework nicht (direkt). Bei Zend_Db ist es so gelöst dass an anderen Stellen innerhalb des Frameworks geschaut wird ob in der Zend_Registry (Klasse ist ein Singleton) ein unter einem passenden schlüssel abgelegtes element sich befinden oder z.b. Zend_Db_Table hat statische methoden + variable wo man die "default-Db-Verbindung" definieren, ansonsten bieten die Klassen auch einen Parameter im Konstruktor bzw. setter um direkt die genutzte DB-Instanz zu nutzen.

Nur MS .NET geht hier noch einen
Schritt weiter und ermöglicht es sogar die Cleartext Config Files zu verschlüsseln damit Kennwort und Username nicht so einfach für externe
ersichtlich sind.

Und wo steht bei sowas dann der Key mit dem die Config/die Einträge verschlüsselt werden ?

Zitat von robo47

Und wo steht bei sowas dann der Key mit dem die Config/die Einträge verschlüsselt werden ?

Wat weiß ich, ist auch nicht relevant. Es gibt ein Kommandozeilen Utility,
das man aufrufen kann um die Config Files zu verschlüssen. Via ASP.NET
kann ich dann jedoch die Datei öffnen und transparent auslesen, als wäre sie
nicht verschlüsselt. Ob die nun mit Public Key Infrastructure Verfahren oder einfach nur mit DES/AES/Twofisch crypten ist mir persönlich wurst.

[Jann Hendrik]

Irgendwo muss es aber ja hinterlegt sein. Andernfalls hätte es den gleichen Schutz wir rot13 - das kann auch jeder Depp auslesen....

Zitat von Jann Hendrik

Irgendwo muss es aber ja hinterlegt sein. Andernfalls hätte es den gleichen Schutz wir rot13 - das kann auch jeder Depp auslesen....

Bei MS sind solche Infos oftmals nicht öffentlich, da kann man nur spekulieren.
Ist aber dennoch egal, da dies einen gewissen Mehrschutz bietet als wie im Fall von PHP oder Java wo es im Klartext hinterlegt ist.