Quelle librairie d'abstraction de base de donnees php

salut tout le monde,

Je voudrais savoir si certains d'entre vous auraient une librairie d'abstraction de base de donnees en php a me conseiller.
J'ai vu qu'il y avait Adodb, pear db2, php pdo ... et j'aurais besoin d'avis eclaires, de retours d'experience sur la question.

merci d'avance

R@f

Ps: desole ya pas d'accents .. clavier qwerty oblige

Salut,

N'étant pas expert en la matière des librairies. Je crois que cela dépend sur quelle SGBDR tu bosses. Si c'est pour Mysql, je ne vois pas pourquoi utiliser par exemple peardb. Il y a suffisamment de méthodes en php pour obtenir ce que tu veux.

++
Modifié par Nolem (14 Jul 2008 - 22:13)

Hello,

Nolem a écrit :
N'étant pas expert en la matière des librairies. Je crois que cela dépend sur quelle SGBDR tu bosses. Si c'est pour Mysql, je ne vois pas pourquoi utiliser par exemple peardb. Il y a suffisamment de méthodes en php pour obtenir ce que tu veux.

Les classes d'abstraction de bases de données servent justement à programmer de telle façon que l'on puisse changer de BDD en ne changeant que quelques lignes de code .

Sinon je suis tombé plusieurs fois sur des tutos parlant de PDO qui m'avait semblé facile à utiliser mais je n'ai jamais pris le temps d'essayer... Donc pas d'avis .
Modifié par Heyoan (14 Jul 2008 - 23:43)

Merci pour vos réponses!

Je pense que je vais rester simple en fait dans l'implémentation, j'ai créé une classe abstraite de laquelle hériteront les classes correspondant aux différents SGBD.

abstract class DatabaseType {

abstract public function connect();
...
}

et

class Mysql extends DatabaseType {

public function connect(){
/* ici le code ..*/
}
}

Je ne sais pas ce que vous pensez de cette solution!

++

Salut,

rafale29 a écrit :

Je pense que je vais rester simple en fait dans l'implémentation, j'ai créé une classe abstraite de laquelle hériteront les classes correspondant aux différents SGBD.

Je ne vois pas trop où tu vas avec ça ... tu comptes ré-écrire les fonctions connect(), disconnect, ... pour les différents SGBD dont tu as besoin?

Tu ne serais pas en train de réinventer la roue?

Sinon, +1 pour PDO (qui est intégré à PHP depuis la version 5.1)

bonjour ,

j'allais justement posé la même question puisque je dois implémenter un environnement php basé sur des tables existantes mais modifiable !!

J'en suis arrivé aux 2 solutions PEAR::DB et PDO et j'espèrais également vos lumières .

Concernant le module PEAR qui'il faut installer , une bonne base pour débuter avec going dynamic with php

Cela ressemble assez à ce que je veux faire mais il y a besoin de faire une mise en place

Concernant PDO (nombreux articles sur le web aussi dont la
FAQ sur developpez.com) à installer ou dé-commenter
Il y a également la première partie d'un article sur le magazine 'phpsolution'

La solution pear::db généralise plus le code il me semble en remplaçant par exemple mysq_query avec execute_query ce qui libère d'une syntaxe particulière d'un SGBD . on peut facilement envisagé un classe de connection générique et des extensions pour les spécificités selon le connecteur utilisés ..

voilà mes premières impressions , qui sont pour l'instant très supeficielles



donc si vous avez d'autres conseils ...

ps : d'accord avec l'avantage pdo avec l'intégration dans php 5 (il me semble qu'il est commenté dans le .ini !non!?)

ps' : pdo semble uniformiser la syntaxe également
Modifié par kzone (16 Jul 2008 - 17:35)

kzone a écrit :
La solution pear::db généralise plus le code il me semble en remplaçant par exemple mysq_query avec execute_query ce qui libère d'une syntaxe particulière d'un SGBD . on peut facilement envisagé un classe de connection générique et des extensions pour les spécificités selon le connecteur utilisés ..

C'est justement le boulot qu'on attend d'une couche d'abstraction, non? Pour autant que je puisse en juger d'après la doc, la classe PDO permet de s'affranchir de ces fonctions. Il "suffit" de changer les paramètres (notamment le driver à utiliser) lors de l'instanciation de l'objet PDO...

La question de l'abstraction et une question que je me suis posé il n'y a pas longtemps mais je n'ai pas cherché de classes existante j'en ai créé une rapidement en me disant que j'ajouterai au fur et à mesure. Ma réflexion a été la même que lorsque j'ai réfléchi sur un système de skin : on ne peut pas produire du code complètement indépendant car si les langages étaient tous les mêmes il n'y en aurait qu'un seul. Du coup j'ai opté pour une classe orientée objet de compatibilité SQL.

Changaco a écrit :
La question de l'abstraction et une question que je me suis posé il n'y a pas longtemps mais je n'ai pas cherché de classes existante j'en ai créé une rapidement en me disant que j'ajouterai au fur et à mesure. Ma réflexion a été la même que lorsque j'ai réfléchi sur un système de skin : on ne peut pas produire du code complètement indépendant car si les langages étaient tous les mêmes il n'y en aurait qu'un seul. Du coup j'ai opté pour une classe orientée objet de compatibilité SQL.

Justement, le code SQL est censé être le même partout, à quelques détails près... La couche d'abstraction est là pour s'affranchir des interfaces entre PHP & le SGBD.

Naturellement, il faut toujours prendre en compte les besoins réels de chaque projet, mais il me semble que ça vaut le coup de se pencher sur les projets existants (PDO mais aussi Propel 1.3, Doctrine & Cie fournissent des fonctionnalités intéressantes, pas évidentes à reproduire tout seul )

Pour PDO l'avantage c'est que c'est intégré à PHP.
Pour Propel et Doctrine voir que ça pèse ( out of the box ) respectivement dans les 2Mo et 13Mo ça me repousse un peu.

Je suis pas encore décidé mais si je change je prendrai sûrement PDO ...

thomas D. a écrit :

C'est justement le boulot qu'on attend d'une couche d'abstraction, non?

oui .... et en lisant un peu plus en profondeur la doc PDO (ce que j'aurais dû faire avant ) c'est quasiment la définition de PDO ....donc j'ai un peu parler pour dire pas grand chose