mon avis date de mi - 2006 , les choses peuvent avoir changées depuis.
ezPDO prend la main sur la BD (il créait même les tables), donc c'est délicat :
- d'utiliser autre chose que ezPDO pour acceder à ta base.
- d'utiliser ezPDO sur une base de donnée existante
ezPDO utilise une unique table pour faire persister les relations entre objets, donc tu peux difficilement dépasser les 20 millions de relations sous mysql 3.2x (d'après moi).
je voulais gérer un id unique par objet ou pour toute la base je ne sais plus, et cela posait pb , je n'avais pas de moyen simple de le faire. A vérifier.
les points positifs :
- à l'époque, la communauté était assez réactive
- c'est cool si tu ne veux voir que des objets (la base se génère automatiquement)
perso j'avais besoin d'attaquer la BD directement pour des stats avancées, et je voulais permettre le développement de module sans ezPDO (ct dans le cadre d'un CMS), et c'etait délicat. J'ai donc mis de coté cette solution.
[^] # Re: ORM ?
Posté par jmny . En réponse à la dépêche Zend Framework 1.0.0 : PHP à la suite de Ruby on Rail. Évalué à 2.
ezPDO prend la main sur la BD (il créait même les tables), donc c'est délicat :
- d'utiliser autre chose que ezPDO pour acceder à ta base.
- d'utiliser ezPDO sur une base de donnée existante
ezPDO utilise une unique table pour faire persister les relations entre objets, donc tu peux difficilement dépasser les 20 millions de relations sous mysql 3.2x (d'après moi).
je voulais gérer un id unique par objet ou pour toute la base je ne sais plus, et cela posait pb , je n'avais pas de moyen simple de le faire. A vérifier.
les points positifs :
- à l'époque, la communauté était assez réactive
- c'est cool si tu ne veux voir que des objets (la base se génère automatiquement)
perso j'avais besoin d'attaquer la BD directement pour des stats avancées, et je voulais permettre le développement de module sans ezPDO (ct dans le cadre d'un CMS), et c'etait délicat. J'ai donc mis de coté cette solution.