Quand vous dites :
« De même, certains aspect de MySQL sont assez « exotiques » avez-vous un bon souvenir de la migration de MySQL only vers PDO ? »
Je ne vois pas de quoi en particulier vous voulez parler, mais en généralisant : la migration d’un code procédural avec l’extension native de PHP vers un code orienté objet avec PDO ne m’a jamais « trop » causé de soucis.
Un léger problème de mémoire avec PDO, lors de l’utilisation d’un fetchAll() plutôt qu’une boucle utilisant un fetch(), mais jamais de problème incontournable (pour ma part)

J’utilise le driver MySQL uniquement car je n’utilise que ce dernier et je ne pense pas passer à un autre SGDB pour le moment.

Cependant, une des raisons qui pourrai m’y pousser serait la libération du code source et donc permettre à d’autre d’utiliser leur SGDB préféré.

Mon application fait grand usage des requêtes de description des et de modification des tables (style DROP, ALTER et SHOW). Avez-vous un retour d’XP positif quand à la bonne compatibilité de PDO même pour ces requêtes ?

De même, certains aspect de MySQL sont assez « exotiques » avez-vous un bon souvenir de la migration de MySQL only vers PDO ?

D’avance merci.

Pour ce qui est de l’utilisation des fonctions non SQL92 (et il y en a un paquet…) peut être un frein pour un portage, et même simplement de la maintenance.

PDO semble être stable à présent et est utilisé dans des projets renommés tel que Doctrine. C’est, d’après moi une bonne base, pour « surcoucher », avec bien-sûr quelques désagrément…

Cela n’est vrai que si on fait du SQL strictement standard. Si on utilise des fonctionnalités SQL spécifiques à un type de base, la portabilité est plus que réduite (et on utilise souvent ces fonctionnalités, car permettent en général de faire de choses avancées, et sont même parfois un critère de choix d’une base de donnée)

Bref, la portabilité n’est pas un avantage, et donc à ne pas mettre en avant, par contre il faut plutôt mettre en avant le fait que l’on a qu’une API PHP à connaître, quelque soit la base de donnée. Quand on passe d’un projet à un autre et qui n’utilisent pas la même base, on connait déjà l’API PHP.

Bon sinon, je suis personnellement assez reservé sur l’usage de PDO. Il a très longtemps été boggué, il y a toujours eu des petites différences de comportement d’une base à une autre, et son API a souvent bougé même si elle tend à se stabiliser depuis quelques temps. J’en sais quelque chose puisque je l’utilise dans mon framework Jelix, et c’est assez pénible de maintenir la compatibilité avec PDO dans des versions stables du framework…

Une transaction est surtout un moyen de s’assurer qu’un ensemble de requetes est soit completement executés, soit pas du tout (respect des propriétés ACID http://en.wikipedia.org/wiki/ACID). De plus, cela ne fonctionne pas avec le moteur de base MyIsam de MySQL. (ce que vous rappellez dans votre billet en lien)

Je ne comprend donc pas votre phrase : « Une transaction est un bon moyen d’optimiser une application en limitant le nombre d’ouverture et de fermeture de MySQL. »

Qu’on utilise ou non des transactions, dans un script le nombre d’ouverture de connexion MySQL est constant : 1.

Que l’on soit ou non dans une transaction, les requêtes agissent de la même manière : elles sont envoyés au drivers, puis à la base, puis l’éventuel réponse est renvoyé à l’application. Il n’y a pas d’optimisation, les requêtes ne peuvent pas être envoyé « toutes à la fois ».