bonjours, je suis en plein debut de developpement, et le referentiel
web de mon entreprise m'impose d'utiliser pear.
ils me laissent le choix (non exclisif) entre DB, MDB et DB_dataobject.
apres une lecture rapide (vraiment?) de l'aide des ces differentes
classes, je suis en train de realiser que l'on doit faire un choix
entre MDB et DB_DataObject, les deux etant destinés a effectuer des
requetes.
l'avantage de DB_DataObject, est, me semble-t-il qu'il est plus ou moin
automatisé (a la maniere d'un windev/webdev), je debute en MDB, mais
il m'a laire plus axé requetes SQL (et surement plus rapide...)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Spot
piti newbee disait le 09/06/2005 16:53:
bonjours, je suis en plein debut de developpement, et le referentiel web de mon entreprise m'impose d'utiliser pear. ils me laissent le choix (non exclisif) entre DB, MDB et DB_dataobject.
Salut, DB_Dataobject est plus concu comme une maniere d'abstraire les tables de la base de donnée et de les tranformer en objets (a la DAO). Perso, pour l'avoir utilisé assez souvent, je pense qu'il faut que tes requetes restent simples, on peut faire des jointures multiples, mais ca peut vite devenir bien plus compliqué a lire que du bon vieux SQL standard. Par contre un gros avantage en terme de prototypage, c'est que tu peut coupler DB_Dataobject a HTML_QuickForm via DB_DataObject_FormBuilder, et ca te permet de creer automatiquement des formulaires de saisie/update de tes tables.
Pour MDB (plutot MDB2 maintant) , ca a plus été pensé comme une couche d'abstraction orientée portabilité, tu peut definir ton schema de DB dans un fichier xml en utilisant des types de données generiques , et toutes les tables sont crées automatiquement par MDB, sinon au niveau de l'api, c'est identique a pear_DB , et d'un point de vue rapidité, c'est a peu pres kif kif...
Et sinon, ben niveau choix, a toi de voir en fonction de la complexité du dev, si tu a beaucoup de SQL costaud, je pense qu'il est preferable de prendre une couche standard DB ou MDB, sinon tu peut te lancer dans DB_DO si tu aimes la synthaxe objet meme jusque dans le SQL.
++ Xavier
piti newbee disait le 09/06/2005 16:53:
bonjours, je suis en plein debut de developpement, et le referentiel
web de mon entreprise m'impose d'utiliser pear.
ils me laissent le choix (non exclisif) entre DB, MDB et DB_dataobject.
Salut,
DB_Dataobject est plus concu comme une maniere d'abstraire les tables de
la base de donnée et de les tranformer en objets (a la DAO).
Perso, pour l'avoir utilisé assez souvent, je pense qu'il faut que tes
requetes restent simples, on peut faire des jointures multiples, mais ca
peut vite devenir bien plus compliqué a lire que du bon vieux SQL
standard. Par contre un gros avantage en terme de prototypage, c'est que
tu peut coupler DB_Dataobject a HTML_QuickForm via
DB_DataObject_FormBuilder, et ca te permet de creer automatiquement des
formulaires de saisie/update de tes tables.
Pour MDB (plutot MDB2 maintant) , ca a plus été pensé comme une couche
d'abstraction orientée portabilité, tu peut definir ton schema de DB
dans un fichier xml en utilisant des types de données generiques , et
toutes les tables sont crées automatiquement par MDB, sinon au niveau de
l'api, c'est identique a pear_DB , et d'un point de vue rapidité, c'est
a peu pres kif kif...
Et sinon, ben niveau choix, a toi de voir en fonction de la complexité
du dev, si tu a beaucoup de SQL costaud, je pense qu'il est preferable
de prendre une couche standard DB ou MDB, sinon tu peut te lancer dans
DB_DO si tu aimes la synthaxe objet meme jusque dans le SQL.
bonjours, je suis en plein debut de developpement, et le referentiel web de mon entreprise m'impose d'utiliser pear. ils me laissent le choix (non exclisif) entre DB, MDB et DB_dataobject.
Salut, DB_Dataobject est plus concu comme une maniere d'abstraire les tables de la base de donnée et de les tranformer en objets (a la DAO). Perso, pour l'avoir utilisé assez souvent, je pense qu'il faut que tes requetes restent simples, on peut faire des jointures multiples, mais ca peut vite devenir bien plus compliqué a lire que du bon vieux SQL standard. Par contre un gros avantage en terme de prototypage, c'est que tu peut coupler DB_Dataobject a HTML_QuickForm via DB_DataObject_FormBuilder, et ca te permet de creer automatiquement des formulaires de saisie/update de tes tables.
Pour MDB (plutot MDB2 maintant) , ca a plus été pensé comme une couche d'abstraction orientée portabilité, tu peut definir ton schema de DB dans un fichier xml en utilisant des types de données generiques , et toutes les tables sont crées automatiquement par MDB, sinon au niveau de l'api, c'est identique a pear_DB , et d'un point de vue rapidité, c'est a peu pres kif kif...
Et sinon, ben niveau choix, a toi de voir en fonction de la complexité du dev, si tu a beaucoup de SQL costaud, je pense qu'il est preferable de prendre une couche standard DB ou MDB, sinon tu peut te lancer dans DB_DO si tu aimes la synthaxe objet meme jusque dans le SQL.
++ Xavier
bruno
Merci beaucoup! je pense que je vait pencher pour DataObject, une version 2 de mon prog. avec plus de table etant en projet, il me permetra peut etre de ne pas avoir a reecrire toutes les requetes....
et puis ses resultats avec link()... ca me tente! Merci de ta reponse.
Merci beaucoup!
je pense que je vait pencher pour DataObject, une version 2 de mon
prog. avec plus de table etant en projet, il me permetra peut etre de
ne pas avoir a reecrire toutes les requetes....
et puis ses resultats avec link()... ca me tente!
Merci de ta reponse.
Merci beaucoup! je pense que je vait pencher pour DataObject, une version 2 de mon prog. avec plus de table etant en projet, il me permetra peut etre de ne pas avoir a reecrire toutes les requetes....
et puis ses resultats avec link()... ca me tente! Merci de ta reponse.
