> Je crois que tu exagères, tu parles du cas où tu vas utiliser les ajouts
> fonctionnels spécfiques des DBAL (gestion des erreurs, transformation de
> ResultSet, etc.)
Non non, je n'exagère pas, et je parle de quand on n'utilise vraiment rien ou presque du DBAL (select classiques)
Pour crédibiliser ce que je dis et donner des chiffres concrets :
Ce sont des chiffres donnés/faits par les dev d'ADOdb eux-mêmes. On peut donc facilement penser qu'ils ont plutot tendance à gonfler leurs perf qu'à les diminuer. Ca laisse quand même 14% pour l'extension C d'ADOdb, et quasi 30% pour la version PHP que tout le monde utilise. Si on s'intéresse à PEAR::DB ça fait du x2 par rapport au mysql direct.
A mon avis et d'après mon expérience ils exagèrent un peu pour PEAR::DB mais dans l'ensemble l'ordre de grandeur correspond à ce qui est trouvé/publié un peu partout et ce que je vois de coté aussi.
14% ça reste largement acceptable, mais on parle de l'extension C que quasi aucun hébergeur n'a et que beaucoup d'entreprises vont hésiter à mettre puisque non offocielle. 30% à 150% par contre ça devient moins rigolo.
Donc oui, c'est intéressant, mais ça a bien un cout non nul.
> Maintenant, avec l'arrivée prochaine de PDO, je pense que la lenteur va encore
> diminuer du fait du codage de la couche en C.
Sauf que PDO n'est *pas* uen abstraction de base de données. C'est bien dommage d'ailleurs parce que l'idée de base est plutot bonne. Il manque très peu pour pouvoir au moins s'en servir comme DBAL pour des besoins simples, mais ça ne supporte même pas de clause offset/limit, ça ne gère même pas les séquences/autoincrement, etc.
Du coup DBO ça te permet juste de garder les mêmes noms de fonction. Malheureusement c'est vraiment la partie la plus simple et automatique dans un portage. Ce qui prend du temps c'est tout le reste ... que ne fait pas DBO.
PDO l'unique but c'est de n'avoir à apprendre/gérer qu'une seule API unifiée. Par contre l'exploitation de l'API reste dépendante du SGBD (et malheureusement les spécificités des SGBD ne sont pas encore implémentées dans PDO donc la migration vers PDO n'est pas réalisable pour pas mal de gens)
[^] # Re: contre
Posté par Éric (site web personnel) . En réponse au journal Petition MYSQL chez Nerim. Évalué à 3.
> fonctionnels spécfiques des DBAL (gestion des erreurs, transformation de
> ResultSet, etc.)
Non non, je n'exagère pas, et je parle de quand on n'utilise vraiment rien ou presque du DBAL (select classiques)
Pour crédibiliser ce que je dis et donner des chiffres concrets :
MySQL 1.14 -
ADOdbext 1.30 14%
dbx 1.37 20% (index only)
ADOdb 1.45 27%
dbx 1.53 34% (index/assoc/info)
PhpLib 1.60 40%
MDB 1.75 54%
PEAR DB 2.87 152% (fetchInto)
PEAR DB 3.15 176% (fetchRow)
M'base 2.52 296% (numeric cols)
M'base 4.77 318% (assoc cols)
Ce sont des chiffres donnés/faits par les dev d'ADOdb eux-mêmes. On peut donc facilement penser qu'ils ont plutot tendance à gonfler leurs perf qu'à les diminuer. Ca laisse quand même 14% pour l'extension C d'ADOdb, et quasi 30% pour la version PHP que tout le monde utilise. Si on s'intéresse à PEAR::DB ça fait du x2 par rapport au mysql direct.
A mon avis et d'après mon expérience ils exagèrent un peu pour PEAR::DB mais dans l'ensemble l'ordre de grandeur correspond à ce qui est trouvé/publié un peu partout et ce que je vois de coté aussi.
14% ça reste largement acceptable, mais on parle de l'extension C que quasi aucun hébergeur n'a et que beaucoup d'entreprises vont hésiter à mettre puisque non offocielle. 30% à 150% par contre ça devient moins rigolo.
Donc oui, c'est intéressant, mais ça a bien un cout non nul.
> Maintenant, avec l'arrivée prochaine de PDO, je pense que la lenteur va encore
> diminuer du fait du codage de la couche en C.
Sauf que PDO n'est *pas* uen abstraction de base de données. C'est bien dommage d'ailleurs parce que l'idée de base est plutot bonne. Il manque très peu pour pouvoir au moins s'en servir comme DBAL pour des besoins simples, mais ça ne supporte même pas de clause offset/limit, ça ne gère même pas les séquences/autoincrement, etc.
Du coup DBO ça te permet juste de garder les mêmes noms de fonction. Malheureusement c'est vraiment la partie la plus simple et automatique dans un portage. Ce qui prend du temps c'est tout le reste ... que ne fait pas DBO.
PDO l'unique but c'est de n'avoir à apprendre/gérer qu'une seule API unifiée. Par contre l'exploitation de l'API reste dépendante du SGBD (et malheureusement les spécificités des SGBD ne sont pas encore implémentées dans PDO donc la migration vers PDO n'est pas réalisable pour pas mal de gens)